Winding down my Debian involvement
michael.stapelberg.ch
michael.stapelberg.ch
Then there is a ton of documentation on creating packages but which 300 page guide is the right one to use is unclear. And which set of packaging tools should I use? In the end, the time investment required to get started has kept me from contributing.
In contrast, with Gentoo and their documentation, it was straightforward for me to make my own additional, separate repo, look at other ebuilds to see how packaging works, and have everything just work.
https://github.com/billsix/billsix-portage
I submit ebuilds to Gentoo itself if I think others would benefit.
As far as I can tell, packaging for Arch is straightforward as well.
It's a monorepo, and packages are declarative. So for most usecases, its just 5-10 LOC describing the source location, dependencies and build process.
After that, if it builds on your local copy of Nixpkgs, it will build on the same Nixpkgs commit as everything is purely functional. A simple PR is all you need.
For updates, there's super low burden too. Thanks to packages being declarative, everything is quite explicit. So a bot can check for source updates upstream, update your package and rebuild it. All it requires is simple maintainer approval.
[1]: https://github.com/NixOS/nixpkgs/blob/fce8f26af6ef8209c7d282...
It won't pass all lintian tests due to the ridiculous requirements and useless ceremony "correct" Debian packages need. Still working on it.
As it turns out, it doesn't take that much effort to make packages that comply with Fedora/openSUSE Packaging Guidelines and Debian Policy with this tool, and it has drastically simplified my ability to maintain software across distributions in a way that still cleanly integrates with the distribution platform.
This is how the Spacewalk Debian/Ubuntu client packages are built[3][4], among many other things. There's also a few other examples out in the wild[5][6][7].
At least for the stuff I make for myself, I haven't made packages that fully pass lintian, but it's not terribly difficult to do if you want to.
[1]: https://github.com/ascherer/debbuild
[2]: https://openbuildservice.org/
[3]: https://gitlab.com/datto/engineering/spacewalk-debian-client...
[4]: https://build.opensuse.org/project/show/systemsmanagement:sp...
[5]: https://pagure.io/python36-flatpkg-deb
[6]: https://pagure.io/rpmdevtools-deb
[7]: https://build.opensuse.org/package/view_file/Virtualization:...
https://github.com/kakwa/amkecpak
It doesn't exactly simplify the Debian packaging in my case as it leaves the packaging mostly exposed.
But it provides a lot of far more convenient and easy to remember commands (make rpm, make deb, make deb_repo, make rpm_repo, etc) compared to the easy to forget options of rpmbuild/mock and dpkg-buildpackage/cowbuilder.
It also glues everything together from upstream source recovery to building the final repository ready to be rsynced on a public server.
https://linuxconfig.org/easy-way-to-create-a-debian-package-...
And then a quality of life enhancement says push the package building off to FPM.
https://github.com/jordansissel/fpm
Personal Repo
https://www.digitalocean.com/community/tutorials/how-to-use-...
This is the root of the Debian newbie community experience. FPM seems to get it at least.
And, at the risk of upsetting people.. it is time to move away from mailing lists, especially for submitting bugs and managing packages.
The new problem is that new people hate emails. I think the merit of this problem is debatable.
So true. There seems like there are competing packaging approaches, some claiming others are outdated while themselves say the opposite.
I've been willing to package a few of my open-source projects as well for almost a year, and out of frustration, I've ended up building my .deb packages manually and hosting them on my own apt repository. In the meantime, I've published a few packages on PPAs (for Ubuntu) and on AUR (for ArchLinux), and it's been as easy as it could have been.
Given I use Debian exclusively on my servers, it feels like a missed opportunity to me (not that I think my own projects are so much valuable to others, but I'd package a lot more stuff if it was clear how to do it well).
I prefer the Void Linux approach - every "template" (equivalent to Arch's PKGBUILD) is kept in a single, monolithic git repository, and the barrier to contribution is kept low; just submit a pull request, and a core developer will review and accept it. This way all packages have binary builds and all packages have had at least nominal review, yet the repository is surprisingly broad. And if you need something that isn't in the repository, adapting an AUR PKGBUILD is trivial.
I've run into the same problems, though I've only wanted to build packages for my own use, or company-internal use.
I think I've understood now how packaging is supposed to work, and have written a guide, shameless plug: http://leanpub.com/debian/c/hn (coupon link to get a free copy; feedback would be appreciated).
I'm just looking through it, for me looking through the epub version the layout is broken (at least viewing using Adobe Digital Editions), apparently every time there's a yellow block with code.
"1.1 Target Audience and Prerequisites" is the first example but I keep finding more.
It eventually got packaged by someone who had been involved in the Debian community for some time.
10 years ago, you had a handful of very idiosyncratic build helpers to help you manage your package.
Today, effectively it's just one [1], debhelper, and it has become trivial to build packages with it. It's a very powerful framework that can be overridden do do basically anything you like, but usually automagically does the right thing. Gone are the days where you had to write an unwieldy debian/rules file.
3 years ago, you had X version control systems supported: git, svn, mercurial, cvs, and who nows what else. Sounds unreasonable, right? Well, when you rely on volunteer work, you need to live with the fact that volunteers will choose the particular tooling they like to work with.
Today, you have Salsa which is a GitLab instance, and people apparently just learned to deal with it, and the world hasn't come tumbling down.
I absolutely agree with the author that some things are just wrong within Debian. However, I believe these are inherent to the nature of an organization comprised entirely of volunteers; achieving consensus becomes really hard because nobody wants to be told how to spend their free time.
On the other hand, being involved in Debian has also been an incredibly formative experience. I believe Debian does some things right that others still fail at or trail after.
But at the same time, I'm not a big fan of other aspects. For example, the fact the packaging is split between at least 3 or 4 files and generally something close to a dozen (at least control, rule, changelog, copyright and maybe .install, .conffiles, .postinst, .preinst, etc) is a bit complex at first specially compared to rpm where everything is centralized into one .spec file.
I'm also not a big fan of how Debian packages handle permission different than root:root. dpkg-statoverride in post install doesn't feel natural, the newcomer while typically use chown, which is wrong. rpm is better in that regard, you explicitly state the permissions in the spec file %files section.
And I'm also not a big fan of Debian renaming upstream archives (<pkg>_<ver>.orig.tar.gz), IMHO, upstream should be taken as it is, including the file name. But that's a minor one and also a very personal opinion.
I've mixed opinions about packages with a lot of scripting to handle a kind of default but slightly customized configuration. I know it can be disabled with "DEBIAN_FRONTEND=noninteractive" but I feel like it's a lot of efforts and an unecessary source of complexity and bugs for a distribution that will primarily be used on servers where such helpers are almost useless specially using tools like puppet/chef/ansible/saltstack.
The tooling also feels a bit like an aggregation of scripts put on top of each. For example, when you want to build in a clean and throwaway environment (aka a chroot), you have pbuilder, cowbuilder, qemubuilder, whalebuilder... CentOS/Fedora has mock. Granted it's less advanced (apart maybe from mockchain) but at least it the obvious choice.
For a lot of things, the Debian packaging feels like Perl: there is 10 ways to do it. But 9 of them are wrong, and you have to go through dozens of pages of policies with no search box (https://www.debian.org/doc/debian-policy/index.html) to figure out the right way. And it's also kind of difficult to follow examples (by downloading source packages to see how it's done) since it's not explicit where each part fits, at least for a newcomer.
Is there something else missing?
Also, cowbuilder runs fine with several instance running at the same time, mock is a bit more sketchy in that regard. Basically, you can only build one package at a time. Typically, it's a bit of an issue for my personal scripts: https://github.com/kakwa/amkecpak, in them I can basically do make rpm -j 42 to build 42 packages at the same time, but with mock/mockchain, the chroot creation has some concurrency issues.
In fairness, I used the rather old mock version packaged by Debian, I've not looked at 1.4, it seems that some of these issues are addressed now.
I've been using it for even longer than that, but I no longer love it. It has declined to being "just OK" in my eyes, which is why I've begun the effort to shift all of my machines to something better.
I've built Debian packages in the past, and after packaging the same software with Nix, it's very hard to not feel that Debian tooling and packaging is time consuming for no good reason. The nixpkgs model, where all you need to build everything is one `git clone`, all you need to make a change is a pull request and wait for a range of automated tests to tell you it's good (for both build and the _uses_ of a package!), and all you need to land a contributed change is click one button, seems strictly better.
Over the years I've heard many people say "but shell scripts, FTP servers and arcane helper tools is the way we've done it for decades and that will never change" in many projects, but eventually, these projects shrink and those with a good developer experience and clean tooling overtake them.
Similarly, after experiencing automatic, safe refactoring across billion-line typed-checked code bases, you can't help but wonder why people put up with spending their time going through heoric community efforts distributing work across people that a machine could easily do if you used good tooling.
In my opinion, the real strength and legacy of Debian is successfully running a large, diverse, distributed project over decades with (reasonable) cohesion, democracy, and (reasonably) good organisation and project management.
But even some non-technical problems go away with good tooling, and more time gets freed up to solve those hard tasks.
Concrete example: In nixpkgs it is very easy to build overlays for the whole of NixOS that allow you to switch from dynamic to static linking or add hardening flags across all packages, avoiding big debates over which is the "one true way" because providing both is so easy, and both can be merged upstream.
I think any big and successful project should continuously invest into better tooling, and simplify and automate things. That keeps contributors motivated and on board.
(14-years happy Ubuntu [and thus Debian] user, and 10-years i3 user, so thanks for your efforts, Michael.)
Interesting article. I had a chance of asking two distributions about some particular feature (making it easier to get GPG keys of developers).
The first one I contacted was Gentoo: they quickly CCed my email to relevant people, discussed the matter between themselves and deployed the change in a week.
Then I contacted Debian about the same thing. The email was basically identical. But the reply was largely negative, complaining about details and openly avoiding work. The entire interaction reminded me of large corporations where any change is met with resistance for resistance sake.
(I use Arch btw.)
10 Minutes after using homebrew for the first time I sent in a PR to update a package to the latest version and update the built dependencies.
(Obviously not that TFA paints a rosy picture..)
It is not a coincidence that the author became demotivated after doing some professional experience.
> On the contrary, older projects tend to be too reactionary when it comes to infrastructure tools, so in turn they get very slow interactions
Well said.
'Open source' doesn't say anything about infrastructure. But it's just as important.
That sounds like a security risk to me.
So that's what the frustrating to maintainers crumbling infrastructure and crappy tooling are for. Now it all makes sense!
Actually, I'd very much prefer quickly pushed updates in case of severe security issues. Debian had lots of really ancient packages with problems in "stable" last time I looked.
Debian's "stable" release is that. Stable. No updates are issued for packages except for critical security updates, which are backported to the released version.
It's essentially an LTS release. This isn't what everyone wants or needs, but if you do, Debian does it very well.
Try updating a single homebrew package to a new major version and watch the other homebrew packages depending on it breaking.
To be fair, that's not a problem unique to homebrew. Gentoo used to break runtime dependencies, too. Although that was a long time ago. Nowadays libs used by other programs are preserved and only deleted when all dependencies have been updated, so breakage no longer occurrs.
I have a lot of trouble with Homebrew on multiuser Mac systems. Running `brew install ...` or `brew update` as anyone but the user who originally installed Homebrew almost always fails because of permission errors (or it successfully installs, but then causes permission errors in the future for the user who installed Homebrew). Whenever I need to use Homebrew commands now, I use `sudo -iu otheruser` to switch to the user account who first installed Homebrew in order to avoid the permissions issues. I'm really baffled that Homebrew doesn't support the multiuser system case. Is it so rare to share a system nowadays? I've had this issue on multiple Macs and fresh installs, so I don't think this is some fluke bug.
Seems to me like either snap or Homebrew Linux are the way to go. ArchLinux also has a reasonable packaging experience.
And that's exactly why I use and trust Debian.
> And that's exactly why I use and trust Debian.
Comments like this are why you are an asshole, mr throwaway30012.
I thought I would try to fix it.
Two hours googling later and I couldn't even work out who the maintainer was. I don't like eating other people's time, but I even tried using IRC.
dpkg -S path/to/file
dpkg -s package-name
In the end I switched all my servers to Ubuntu. It's been good and I love PPAs.
The bug was rather quickly marked as confirmed, with absolutely no updates for several years, even though the root cause was known. As far as I know, it still hasn't been fixed.
The bug remains to this day.
Oh, so much this. The crappiness of bug reporting for Debian has meant that I stopped trying to report issues years ago.
I suspect with that I can probably find the repository, so that I can check whether the comment has already been fixed, then I can work out how to submit a patch or bug.
I am a developer so every now and then I make a concerted effort to diagnose a bug, then fix it, then do a pull request.
However, I do admit I usually give up before getting to the point of submitting something useful...
In the case of config files, this only seems to work sometimes -- maybe if it wasn't modified by the user? Or if it came from a package directly, and wasn't generated from its {pre,post}inst scripts?
$ dpkg -S /etc/hosts
dpkg-query: no path found matching pattern /etc/hosts
$ dpkg -S /etc/resolv.conf
dpkg-query: no path found matching pattern /etc/resolv.conf
$ dpkg -S /etc/bash_completion
bash-completion: /etc/bash_completion #!/bin/bash
set -e
set -u
if ! [[ ${1:-} ]]; then
echo please provide a file
fi
dpkg -s $(dpkg -S "$1" | cut -d: -f 1) | grep MaintainerI always wondered if Debian/Ubuntu could benefit from a "monorepo". It seems to work for other distributions, e.g. Alpine Linux and Homebrew.
https://github.com/alpinelinux/aports/tree/master/main
Right now every Debian package lives in a separate repo, or it doesn't even have to live in a repo at all AFAIK.
I think Debian has the most packages because their process is very loose and decoupled (as well as it being one of the oldest distros). But having tighter integration does help move things forward faster.
I wish they went all in and used GitLab Issues for bugs and GitLab CI/CD to auto-build packages for both validation and pushing new packages into the Debian repositories.
I love using Debian, I care deeply about Debian Policy and Debian's procedures, I enjoy many aspects of the Debian community, and I'm also well aware of where Debian has difficulties.
There are advantages to both ways. However, a single repository permits changes to multiple packages in a single change. In Debian, simple transitions which affect multiple packages can take months or even years to fully propagate through the entire system. Not due to technical difficulty, but the logistics of coordinating the change.
Debian's approach made sense at the time. Developers who were widely distributed, communicating sporadically using dial-up internet connections, needed to be able to work independently and changes which had wide-ranging effects needed discussion and coordination. Nowadays, that can happen on a single merge request on GitLab. Homebrew can do such changes in a single pull request.
Today, when you submit e.g. a homebrew PR, it gets comprehensively tested by CI builds, including rebuilding and testing all reverse dependencies on every supported platform version. The BSD ports changes are backed by poudriere builds of the entire collection, again on multiple versions.
Services like GitHub and GitLab allow one to hook in all sorts of stuff and greatly improve the ease of submission of large- and small-scale changes, as well as making thorough testing and review both possible and accessible. Older projects are stuck with older entrenched tools and infrastructure, and haven't taken advantage to newer ways of doing things which newer projects have been able to adopt wholesale. The Debian tooling and infrastructure is certainly dated, but it's also of extremely high quality and very robust.
https://github.com/stapelberg/hugo/blob/master/content/posts...
display: flex;
flex-direction: reverse-column;
Feel free to message me if you're confused and would prefer a fast PR, but you strike me as someone who wouldn't mind learning a bit & I'm in Morocco with limited internet.
edit: I would also move the branding (name & logo) above the content so people know who they're reading. And adjust the margins a bit. Frontend is Fun.
Tone: Honest question. What's that, exactly?
I've been trying to figure that out off and on for the last, oh, 5 or 6 years, and I keep bouncing off the problem as being too complicated to be worth it for my personal site. If there's a clean answer that has developed in the time since I basically gave up, I'd (again, no sarcasm) love to hear it. But I'd probably need a link to something; Google is clogged with old stuff here.
If I write:
@media (max-width: 500px) {
p {
font-style: italic;
}
}
Let me know your Paypal, if you have any, and I’ll gladly invite you for a virtual coffee as a sign of my gratitude :)
Glad it worked for you!
On the other side of the spectrum, I've found that the official binary repositories for Arch Linux suffer many of the same issues described in the article for Debian. Patches being ignored and collaboration or involvement being near impossible. Even worse, the few people in charge of the official repositories are allowed to basically remove packages from the AUR with no interaction with the AUR maintainer, for the purpose of "promoting" them to the official repositories. This has happened to me twice, and it resulted in what I think is a worse package in one of those cases.
>On the other side of the spectrum, I've found that the official binary repositories for Arch Linux suffer many of the same issues described in the article for Debian. Patches being ignored and collaboration or involvement being near impossible.
Well, we still relay on svn internally so things are complicated to say the least. Even if we had things on git (which we are working on), I'm unsure if opening stuff up for outside collaborations like gentoo, alpine, void and nixos does is a good way. You need the proper tooling setup to make sure this isn't a burden on the maintainers.
>Even worse, the few people in charge of the official repositories are allowed to basically remove packages from the AUR with no interaction with the AUR maintainer, for the purpose of "promoting" them to the official repositories.
Which is true. Some people email maintainers of complicated packages before inclusion, and some also gives a headsup in the comments of the AUR. However, this is all done if the packager want to. There is no rules here. The removal is on the grounds that AUR packages shouldn't overlap with official ones.
>This has happened to me twice, and it resulted in what I think is a worse package in one of those cases.
I'm interested taking a look at this if you want :) foxboron@archlinux.org or just type in the comments.
I'd rather not, the thing in question was around three years ago and I don't think I even have my AUR PKGBUILD for comparison. It wasn't a cry for help, and I'm not naming packages or individuals for a reason. Just voicing some frustration at the process.
The last straw was this: https://lwn.net/Articles/704608/
"""When I joined Debian, I was still studying, i.e. I had luxurious amounts of spare time."""
OSS has stopped (if it ever truly was) being a part time endeavour. I know from bitter personal experience one cannout up with a lot of bureaucracy and process of it is your day job - you have time to get through the rubbish in order to find the diamonds.
How we (as a society now utterly dependent on OSS) manage this problem is on a par with how we manage journalism - they are bigger questions than I have easy answers to
I think that depends on what OSS crowd you want to run with. The part-time hobbyist sector may be, I think, stronger than ever before.
The difference now is that there exists the "commercial" OSS sector. That is certainly not part-time hobbyist.
There is some overlap between those two worlds, but they are very different and distinct worlds nonetheless.
Btw. You changed from .name to .ch I noticed... Trying to naturalize? ;)
The problems listed are precisely the kind of problems that Redhat strategically supports fedora with, in terms of investment of resources. For all the hate Redhat receives it has consistently been a good community member by being willing to help fedora in areas that it knows are hard and yet not 'cool' enough to attract volunteer contributions.
What has Ubuntu done for the debian community along the same lines?
If I wanted to start being a contributor to a distribution, which one would be the best to dive in to?
There is probably an impact graph with popularity * impact of change on the project * probability of change being accepted * log(delay of change reaching 80% of users).
For instance with Homebrew: high popularity, high probability of being accepted and low delay to reach 80% of users, so the impact of the change on the project is the main factor.
I tried to contribute a package to Fedora once upon a time...gave up in frustration after a while since it went nowhere after a bit of hoop jumping.
The process is pretty well documented here: https://fedoraproject.org/wiki/Join_the_package_collection_m...
If you have issues, feel free to hop into any of the Fedora communication channels[1][2][3][4][5] and ask for help.
[1]: https://fedoraproject.org/wiki/Communicating_and_getting_hel...
[2]: https://fedoraproject.org/wiki/Telegram
[3]: https://discord.gg/fedora (Yes, Discord!)
[4]: https://discussion.fedoraproject.org/
[5]: https://fedoraforum.org/ (Unofficial, but a strong, helpful group!)
We also have a cool website that helps you figure out what you want to do and how to apply it: https://whatcanidoforfedora.org/
(Yes, it's inspired by the Mozilla one!)
Open question: If Debian contributors feel the need to drop out and move on due to these pain points, are there less-painful Linux-distribution projects out there that are getting more of these pain points right they can flock to? Is this a sign that Debian needs to reform, or that other, newer distributions are outpacing it?
Watch out for what packages you rely on, and what repository those packages come from. If they're in universe, expect your bug reports on Launchpad to go unanswered or unresolved. The only way to get fixes in them is to go upstream to Debian. But note that not every bug in a universe package is actually fixable or broken in a Debian world, because the bug might be down to interactions between a decision made by Canonical with packages in the main repository, and those for the universe package.
Ubuntu is currently divided into four components: main, restricted, universe and multiverse. All binary packages in main and restricted are supported by the Ubuntu Security team for the life of an Ubuntu release, while binary packages in universe and multiverse are supported by the Ubuntu community.
https://wiki.ubuntu.com/SecurityTeam/FAQ
If you care about security, disable universe and multiverse on servers, or use Debian Stable if you want a Debian-based distribution.
The closest counterpart is SUSE's PackageHub, which is often seeded by stuff going into openSUSE Leap that isn't part of SLE itself.
I would love it if Red Hat were to give it proper recognition. I honestly don't know why they haven't yet...
Ubuntu specifically has a "server" version. I've been using it since 10.04 (almost 9 years) and never had to use anything else.
Sadly, like most big organizations, it is hard to implement changes from inside.
In my opinion, most Debian's issues stem from a centralized imperative package manager where all packages need to be carefully kept in sync for things to work. Moving to something like Nix would greatly simplify development.
This is far from a new idea. In fact, it was quite thoroughly discussed in debian-devel mailing list back in 2008, 2013 and several other times [1].
[1] https://lists.debian.org/debian-devel/2008/12/msg01007.html
When I first used Debian in the 90s it had a reputation for being slow and bureaucratic.
That said, I agree anything Debian (and thus Ubuntu too) and FSF feels awkwardly baroque to work with these days.
Old email-based systems, bickering over politics and minor issues rather than the subject at hand, for weeks or months... and no standard CI?!?
With all that I too find myself spending my time contributing elsewhere.
It’s a shame as these 2 organizations acts as a fundament for sooo many things I rely on daily, but I just can’t bother.
It’s stable and I know they’ll still be around 5 years from now.
They also very rarely break anything on updates.
There are only three Linux distress I’d run in production, RHEL, Debian or Ubuntu (depending.
Sending patch-files by email and then having to discuss/defend your patch for weeks, only to have to create and send a new one, leaving receivers to diff patch-files to see what is different...
Let’s just say in 2019 you expect something a little more sophisticated to be available to make your contribution easier.
email-only interaction can be massively inefficient. For larger changes, I might need to change the severities, tags, and follow up to dozens of bugs. For every metadata change I make, I need to check the reply to make sure the change took place. That means manually tying together sent emails with BTS replies and repeating any which failed.
I used to track all this on large pieces of paper! I shouldn't need a manual system to manage my interaction with an issue tracking system. When I press submit in any other system, the effect is immediate. This is hugely costly in terms of time and effort to do really trivial and mundane things. It's one thing to do it once, but what happens when you make 30 changes and have to wait 20 minutes for each request to round-trip? It's a logistical nightmare which can take several hours to complete.
If I was to highlight a single problem with the Debian BTS, it's that there was a failure to acknowledge its inefficiencies and look at other systems. The criticisms raised in this thread aren't new; they were known 15+ years back. There's a reason why the others are not using email as their primary mode of interaction, and it's a shame the BTS didn't get a decent web frontend to make it more efficient as well as more accessible.
Hmm, in my opinion, this is good thing, not an issue needs to be solved.
What helped me a lot with Nix is that you can easily make your own local derivations. Derivations are usually short [1] and bear little risk with sandboxed builds enabled. Basically, you do a nix-shell -p mypackage, you get dropped in a shell with your derivation, but it does not affect the rest of your system.
[1] Example of a C++ library: https://github.com/danieldk/nix-home/blob/master/overlays/30...
For RPM-based distros (e.g. openSUSE), you write a .spec-file, check it in via OBS's version control alongside your sources, and off you go. OBS builds the package (and pulls in dependencies as needed etc.) and publishes the result as a repository with GPG keys and all the jazz, which you can just add to your own distro, and which is openly visible, so everybody else can use your package(s), too.
OBS also supports forking existing packages, and you can merge them back together, which means you can fix something in an existing package (whether a distro-package or something somebody else put up) and if they accept the changes, congratulations, you just fixed something in the distribution.
This means a lot of building, compilation, versioning etc. is out in the open, and you always have the sources available on top of it.
As an aside: I doubt people will "flock" to openSUSE, since many people sneer at them for no good reason (YaST, still?!), but they do a lot of good work, are good upstream contributors (like RedHat and unlike Ubuntu) and some of the tooling is absolutely amazing, except that nobody really knows about it.
[0]: https://en.opensuse.org/Portal:Build_Service
[1]: https://fosdem.org/2019/schedule/event/distribution_build_de...
I have recommended it to others who need a stable Linux distro with lots of well-maintained packages. Some of them looked at me like I was crazy. Preconceived notions are hard to overcome sometimes. Oh well.
Ubuntu exploited a clear gaping hole in the distro market in 2004. There's still a gap in 2019, but it's a weirder market now than it was back then.
To me as an outsider the obvious cause for Debian obsolescence is, and has been for more than a decade, the growing bureaucracy and consequently the lack of new blood and innovation. This opinion anchored the day when, participating to a Debian bug squashing party surrounded by similarly minded hackers, we were approached by a DD asking if he could check our identity papers in order to "simplify the process" of accepting our fixes.
Organisations, and companies too to some degree, can sometime be best described by what they stand against. Since the beginning Debian has been standing against a hostile environment: I mentioned already the industry bad practices, but also part of this hostile outer world were the negligent upstreams, the unaware users, the cheating corporations and the misguided FOSS enthusiasts. Some bureaucracy was certainly in order to protect against them all. But I'm afraid one of Debian legacy will be that the DD will personify the FOSS bureaucrat, with its 300 pages long packaging manual and 30 steps long contributor approval processes, in the cultural pantheon of the distributions of the future.
Using reportbug or e-mail feels way less comfortable in comparison.
I've known people who can provide high quality, detailed bugs, decide not to because the extra hassles in reporting to Debian just aren't worth it to them.
And I've seen Debian package maintainers fail to file bugs correctly....
One of the principles of the Debian Social Contract reads:
We will not hide problems. We will keep our entire bug report database open for public view at all times. Reports that people file online will promptly become visible to others.
Dissuading people from filing bug reports feels like it's not in the spirit of this principle. You're basically hiding problems because you don't think the problem reporter is worthy.
You might have a massive problem with a default option, but it's not reported because the people savvy enough to handle the bug reporting can fix it themselves. But that might mean most people using your software are getting a bad impression and most ordinary users are put off.
Depends on whether you're trying to create an elitist grouping or create something to fill people's needs.
It's an interesting, though not unexpected, position that demonstrates technocratic societies can have the same problems of control of power that capitalist societies have; except instead of the elite controlling access to money resources, they control access to technological abilities: "fix it yourself" might be the parallel to saying to a homeless person "get a job".
It's an interesting revelation to me of how a meritocratic society can fail to be egalitarian.
There are tools like reportbug which already help to filter out inappropriate use by asking simple questions and doing basic checks. I'm sure that could be further improved to help triage and improve submissions.
As a maintainer, I frequently needed to change bug tickets. Tags, versions, dependencies, and other details. All need doing through the control@ email interface. Changes can take over half an hour to be processed and acknowledged. It's inefficient and tedious, and prone to error if there's a single typo. While I'm not a fan of web interfaces, bugzilla, JIRA, gitlab issues etc. are all a world more effective and efficient to use.
The Debian BTS does what it does well. However, the other systems all do a much better job. The Debian BTS is a couple of decades past its prime. Nowadays we don't need email interfaces to services like this, we have much simpler and more immediate ways to talk to services, which are even easier to script for non-interactive use.
Take a typical interaction. I need to respond to a ticket I didn't originally file or get CC'd on. With any other system, I'd log in, find the ticket, make a comment and any metadata changes, and press "submit". With the Debian BTS, I need to find the ticket, download the mbox mailbox by hand and open that in a mail client by hand, then find and reply to the relevant message(s) and make any other needed changes using the control interface. It takes much longer, and it wastes huge quantities of valuable time. It is not a pleasure to use.
I can not understate what a huge time sink it is to use the Debian BTS to work with dozens of tickets every day. It's an exercise in frustration.
The fact that you need to jump through these hoops to respond so that people will see your reply is another reason why it's a really painful and inefficient workflow.
It’s hard to make a change on the inside when so many people’s lives depend on not making that change.
Maybe Debian needs to go through a OpenWRT/LEDE split. That was over a lot of resistence to change and general bureaucracy. In the end, they merged back after fixing the biggest problems.
Thankfully, most companies (including FAANGs where I worked) are way more careful than that.
Flashy UIs change every day, really critical systems are kept very stable...
We're making a lot of progress with Debian Rust packages and have automated away 90% of the ordinary Debian crap - which is needed in the general case but not for Rust where the constraints are very well-defined by Cargo - you only have to maintain two files (d/changelog and d/copyright) for the vast majority of Debian Rust crates.
It seems designed to address a lot of these issues?
* Granting personal freedom to individual maintainers
* All maintainers need to read up on what the new thing is, how it might break, whether/how it affects them, manually run some tests, and finally decide to opt in.
To this day, the Debian community is the only community where I have not been able to get past the initial stages to get involved. And you don't have to look too hard to see that I'm in quite a few communities...
There's a lot of parallels to Debian and Fedora when I started in the project over a decade ago.
The clear divider in how the two projects evolved was that Fedora elected to implement a lazy consensus model for decision-making, and developed a culture with a bias for action and improvement. Debian requires full consensus (generally) and has a culture that favors inaction. This difference is what has kept me in the Fedora Project for over a decade, and I still enjoy working in that community and doing my part to improve the greater Linux community and ecosystem.
Over the years, Fedora shed a lot of its more complex processes and developed simpler tools and supporting infrastructure to make it easier to use and contribute to the development of the distribution and outlying projects. Over the years, I've seen us replace our buildsystem infrastructure[1][2][3], develop APIs and protocols for weaving tools together[4], migrate SCMs and create the first ever binary store system for Git[5][6][7], develop tools to simplify complex tasks[8][9][10], and build replacements to proprietary or overly-complex systems and support open standards and interoperable systems[11][12], all to benefit our users, our contributors, and our ecosystem. We've taken a similar hammer to our processes and structures so that we enable a wider range of people to be involved, representing their concerns and making our community healthier than before.
We're still continuing down this path of making it easier for people to leverage the Fedora Project resources for the benefit of the community with things like COPR[13], CI on packages with Koschei[14] and CentOS CI integration for projects and packages[15], etc.
That's not to say Fedora is perfect, mind you. It still has some technical and process warts. But I'm proud of the fact that our community is still actively trying to improve our processes, our tools, and our distribution. We're not afraid to make things better, and our community generally wants to make the Linux world a better place.
[1]: https://fedoraproject.org/wiki/FedoraSummit/NewBuildSystem
[2]: https://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerg...
[3]: http://koji.build/
[4]: https://fedmsg.readthedocs.io/en/stable/
[5]: https://fedoraproject.org/wiki/Dist_Git_Proposal
[6]: https://fedoraproject.org/wiki/Dist_Git_Project
[7]: https://github.com/release-engineering/dist-git
[8]: https://www.mankier.com/1/fedpkg
[9]: https://bodhi.fedoraproject.org/docs/
[10]: https://mirrormanager.readthedocs.io/en/latest/
[11]: https://pagure.io/pagure
[12]: https://ipsilon-project.org/
[13]: https://copr.fedorainfracloud.org/
The Gmane web interface is not just down but shut down for good: https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/com...
So this issue won't get better without Debian doing something themselves.
debain is the base for so many other projects, it needs to keep going strong.
in the meantime debian in many aspects is a bit "old" now, its infrastructure and the way to do things need evolve. I'm not a developer per se, it is not easy to become one either.
There are so many ways to make packages and it's hard to pick the "best" one for example.
I hope Debian can reform its model to make it even better, there are just so many archaic baggage from the past for new comers.
Thanks for writing this. I wrote a response here: https://changelog.complete.org/archives/9971-a-partial-defen...
The tl;dr version is I agree with you about some of the things you mention, but also feel like there's an element of personal preference for web-based tools showing through.
Today, keeping packages under version control is considered good practice, but even today it's not mandatory as far as I'm aware.
While other systems, like the BSD ports, are in a single repository, this complete separation has had its advantages. The system is almost completely modular, with all the interdependencies explicitly documented. It's easy to add third-party packages. Look how easy it is to add extra BSD ports packages. You have to fork the entire thing because the repo doesn't just include the packages, it includes all the build infrastructure. This makes building third-party ports a bit more of a pain, because it wasn't considered important, while for Debian it was a fundamental design goal. On the flip side, making a patch for the BSD ports is the same for every single package and it takes just a few minutes to attach it to a bugzilla ticket.
Seriously though, I'm amazed at how well Debian just works. And I know it's because enough people are willing to put up with these types of frustrations. Thanks for the hard work.
As an outsider, to me the list of complaints sounds kind of petty and whining. Better to just say "I'm moving on, I wish everyone the best" and be done with it.