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?