Most debian-based Linux distributions are using a quite complex package development workflow. In my experience, it is at least so complex than all the commonly used technologies today for professional software development (most commonly: git + CI deployment scripts). While it is very badly documented, it is full with oldie things targeting oldie problems.

There are also serious problems to solve, if someone wants to distribute his software as deb packages. Although debian and the related distros are all open-source...

  • becoming a package maintainer is a huge overhead, requires also a social integration and many communication on their mailing lists,
  • packages need to fullfill a lot of (mostly unneeded, archaic) packaging requirements/standards,
  • and even in the best case it will be included in the next stable distribution (meaning years of overhead).

These seem for me practically unfullfillable requirements if I only want a place, where I can upload my code, and it becomes automatically included into an apt repo, where everybody will be able to use it.

Thus, I think the current deb system has a too rigid structure, does not follow best-practice standards, and it has an unfeasible administrative, social and technological overhead. It was a good practice some decades ago, when source code management was not really common (git did not even exist), and software was distributed mainly in downloadable .tar.gz files.

Launchpad has initiated an option for a free package management system, but it has many disadvantages:

  • it has zero SCM integration
  • it has zero CI integration
  • it likes only Ubuntu (ok, most ppa can be used also from Debian)
  • source package upload with its - unneeded - signatures is a nightmare (for example, I am not sure, anybody can still remember, what are those required ".changes" files for that and why are they required). Also gpg became a nightmare since gpg2 (example).
  • slow. It takes about an hour from the source upload and to the appearance of the compiled binary package in the apt repository. This is mostly unneeded.
  • creating dependencies across ppas is impossible. This avoids to create a free, fluid community. Only independent personal package archives can be created, what can't grow once into even a distro fork.

My opinion is that here we have the problem, that old customs becoming unfeasible today, are bonding us due to the social inertia.

Instead, the correct development workflow would be far more easy:

  • to debianize a package, we should need to fork its git repository
  • its debianization should exist on a branch (in our repository), for example on the branch name "debian"
  • upstream changes/developments should be simply merged into it with the git
  • a CI software - integrated into the git server - should automatically rebuild the package on every push, and deploy it, easily, into a downloadable apt repository.

For that, already a lot of opensource software exists:

  • gitlab can be used for newbie-friendly source code management
  • a gitlab runner (even from a different machine) could execute the package building/deployment script, automatically on push,
  • reprepro could be used to generate the apt repo and deploy the packages in it
  • the apt repositories could be publicized on http/ftp with any http/ftp server, as usual.
  • apticron could be even used to automatically install it on the systems.

This would make also a lot of simplifications possible. For example, the all packages could have the "native" source format. In my opinion, having a patch manager which simply patches an unmodified upstream source, is sub-optimal. Patches should be managed by git, of course the ideal is if it is close to the upstream source.

I am thinking on to create a free service, using gitlab and gitlab CI, but what would be integrable also with other free source management sites (github.com, gitlab.com).

However, my problem is that it will be probably not very well used. I don't want to invest a lot of time and (possibly) a lot of money into a free service, what will be used probably only by me.

What to do?

  • About the close vote: my goal is to refresh the debian packaging workflow and customs, or to make at least the possible highest impact into this direction. Anybody having more experience with the opensource community, can say the best practice for that. On this reason, I am arguing against the opinionatedness of the question, but I am open to any improvement suggestions to avoid the closure.
    – peterh
    Commented Dec 20, 2019 at 18:48
  • you'd have to hash that out with the Debian folks. This site has no say in what/how they do their hobby.
    – vonbrand
    Commented Mar 1, 2020 at 17:10
  • @vonbrand The idea is about to extending the existing deb-based distros with the packages of the people whose hobbies/customs are not enough compatible with the debian standards (for example, they don't want to wait years until their package is included in the main repos and so on). The question does not convince the debian (ubuntu) folks and their work; it wants to extend it.
    – peterh
    Commented Mar 1, 2020 at 19:21


Browse other questions tagged or ask your own question.