3 ms·

I like Debian and have entertained the thought of becoming a Debian developer multiple times. The learning curve for a new developer is steep. Just packaging a

by Tepix 6y ago

I like Debian and have entertained the thought of becoming a Debian developer multiple times. The learning curve for a new developer is steep. Just packaging a small piece of software requires a large amount of documents to consider last time i looked.

qiqitori 6y ago
Maybe, but you will be able to use some of the knowledge or intuition gained if you ever have to package something for any other distro.
- nix23 6y ago
  So AUR is the better choice? pkgsrc? At least you don't have to read tons of Docs.
- Tepix 6y ago
  Packaging something for my own use (or my company's) is quite different.
danieldk 6y ago
It is a tiresome process. I attempted to submit a particular package (and others before and after me). It was either met with a lot of red tape (IIRC document licenses for each file individually) and months of no visible progress when comments were addressed. This was in stark contrast to e.g. contributing to nixpkgs. Do a PR on GitHub. The package gets built automatically by CI. Get feedback. Make changes to address the feedback. And it gets merged. Of course, PRs sometimes go stale (most projects are dealing with a lack of manpower), but the process is generally fast. But the outcomes are radically different: I never attempted to contribute to Debian again, but I have become an active contributor to nixpkgs. I think to attract developers the process needs to be modernized. Put all the package definitions in a Gitlab monorepo. Build each PR in a sandbox on CI. Describe the submission process on a single page.
- ylyn 6y ago
  Debian cares a lot more about licensing than Nix. Debian also has far more developers than Nix, I imagine, and processes that have probably existed for longer than GitHub itself.
  - pantalaimon 6y ago
    > processes that have probably existed for longer than GitHub itself. There is a saying in German that goes > Wer nicht mit der Zeit geht, geht mit der Zeit. Now Debian has lot inertia and Ubuntu is a huge factor too, so there are enough incentives for people to put up with that process. Also, maybe this is by design. By keeping the bar for every high, maintainers are not bothered by low effort PRs.
- wink 6y ago
  Back when I was eager to join they still had this ridiculous several month or 2 year long process to get in, so after reading a few accounts of that I said screw it and never even tried again, even when they changed that. I guess I wasn't the only one, and in the end I joined other projects where contributing was fun and easy. (And yeah, I'm neither someone to start projects nor spending consistent time every week, but that doesn't mean you can't contribute lots of time). Still a happy Debian user after all these years, but I'm past the time where I'd spend effort to even try to join.
- rleigh 6y ago
  The processes are a legacy of distributed development in the era of dial-up internet. No always-available services, no github, not even any requirement for version control. With every package being maintained independently. While most packages do now use version control, every package has the potential to use a different system, and internally could use a different set of tools to do the actual packaging work. If you were to design the .deb packaging workflow today, you'd do it very differently. You would probably have a single, or much smaller, set of source repositories, and you would have a single tool to do all the core packaging work. You only have to look at the BSD Ports, MacPorts, Homebrew, vcpkg, and other software collections to appreciate how extremely complex the Debian approach is, and how the other systems benefit from a strictly standard set of functions to do their job, making all packages uniform and easy to work on. On the other hand, because of these considerations, Debian has vastly better support for complex versioned dependencies, and the SAT solver in apt is best in its class. The other systems manage the collection as a whole and don't need to care to the same extent. So I would agree some modernisation wouldn't go amiss. But it's difficult to accomplish that when you have a 25 year legacy of doing it a completely different way. And you have over 20000 packages to fix.
secondcoming 6y ago
Yes, I gave up trying to package a small utility.
foresto 6y ago
On the other hand, those documents are well organized and clearly written, which makes skipping around to just the parts you need rather easy. A wealth of example material and helper tools (e.g. lintian) are also available, and all the policy changes are versioned and described as human-readable diffs[1], so the cost of catching up if you haven't been following progress for a few years is quite low. I think my first simple debian package was working within a few hours, and I was tackling more complex stuff within a few days. Not bad for a system that can handle the oddball installation requirements of just about any software, while also accounting for many install/configure/upgrade/downgrade/reinstall/remove edge cases. I'll grant that it is a complicated system, and there's a lot of legacy stuff beneath the higher-level tools. I suppose my point is that the vast majority of the complexity turns out to be avoidable in most cases, and getting started is not as hard as it looks. [1] https://www.debian.org/doc/debian-policy/upgrading-checklist.html https://www.debian.org/doc/debian-policy/upgrading-checklist...

by Tepix 6y ago

qiqitori 6y ago

Maybe, but you will be able to use some of the knowledge or intuition gained if you ever have to package something for any other distro.

nix23 6y ago
So AUR is the better choice? pkgsrc? At least you don't have to read tons of Docs.
Tepix 6y ago
Packaging something for my own use (or my company's) is quite different.

danieldk 6y ago

It is a tiresome process. I attempted to submit a particular package (and others before and after me). It was either met with a lot of red tape (IIRC document licenses for each file individually) and months of no visible progress when comments were addressed. This was in stark contrast to e.g. contributing to nixpkgs. Do a PR on GitHub. The package gets built automatically by CI. Get feedback. Make changes to address the feedback. And it gets merged. Of course, PRs sometimes go stale (most projects are dealing with a lack of manpower), but the process is generally fast. But the outcomes are radically different: I never attempted to contribute to Debian again, but I have become an active contributor to nixpkgs. I think to attract developers the process needs to be modernized. Put all the package definitions in a Gitlab monorepo. Build each PR in a sandbox on CI. Describe the submission process on a single page.

ylyn 6y ago
Debian cares a lot more about licensing than Nix. Debian also has far more developers than Nix, I imagine, and processes that have probably existed for longer than GitHub itself.
- pantalaimon 6y ago
  > processes that have probably existed for longer than GitHub itself. There is a saying in German that goes > Wer nicht mit der Zeit geht, geht mit der Zeit. Now Debian has lot inertia and Ubuntu is a huge factor too, so there are enough incentives for people to put up with that process. Also, maybe this is by design. By keeping the bar for every high, maintainers are not bothered by low effort PRs.
wink 6y ago
Back when I was eager to join they still had this ridiculous several month or 2 year long process to get in, so after reading a few accounts of that I said screw it and never even tried again, even when they changed that. I guess I wasn't the only one, and in the end I joined other projects where contributing was fun and easy. (And yeah, I'm neither someone to start projects nor spending consistent time every week, but that doesn't mean you can't contribute lots of time). Still a happy Debian user after all these years, but I'm past the time where I'd spend effort to even try to join.
rleigh 6y ago
The processes are a legacy of distributed development in the era of dial-up internet. No always-available services, no github, not even any requirement for version control. With every package being maintained independently. While most packages do now use version control, every package has the potential to use a different system, and internally could use a different set of tools to do the actual packaging work. If you were to design the .deb packaging workflow today, you'd do it very differently. You would probably have a single, or much smaller, set of source repositories, and you would have a single tool to do all the core packaging work. You only have to look at the BSD Ports, MacPorts, Homebrew, vcpkg, and other software collections to appreciate how extremely complex the Debian approach is, and how the other systems benefit from a strictly standard set of functions to do their job, making all packages uniform and easy to work on. On the other hand, because of these considerations, Debian has vastly better support for complex versioned dependencies, and the SAT solver in apt is best in its class. The other systems manage the collection as a whole and don't need to care to the same extent. So I would agree some modernisation wouldn't go amiss. But it's difficult to accomplish that when you have a 25 year legacy of doing it a completely different way. And you have over 20000 packages to fix.

secondcoming 6y ago

Yes, I gave up trying to package a small utility.

foresto 6y ago

On the other hand, those documents are well organized and clearly written, which makes skipping around to just the parts you need rather easy. A wealth of example material and helper tools (e.g. lintian) are also available, and all the policy changes are versioned and described as human-readable diffs[1], so the cost of catching up if you haven't been following progress for a few years is quite low. I think my first simple debian package was working within a few hours, and I was tackling more complex stuff within a few days. Not bad for a system that can handle the oddball installation requirements of just about any software, while also accounting for many install/configure/upgrade/downgrade/reinstall/remove edge cases. I'll grant that it is a complicated system, and there's a lot of legacy stuff beneath the higher-level tools. I suppose my point is that the vast majority of the complexity turns out to be avoidable in most cases, and getting started is not as hard as it looks. [1] https://www.debian.org/doc/debian-policy/upgrading-checklist.html https://www.debian.org/doc/debian-policy/upgrading-checklist...