Live data from Hacker News

20 years as a Debian maintainer

suihkulokki.blogspot.com

31–40 of 126 posts

Re: 20 years as a Debian maintainer

#31
post #10

Earlier quoted context omitted.

Sorry, I meant to write AppImage not flatpak. The point was that a lot of packaging would be done by the devs, allowing minutes maintainers to so more important stuff.

I don't think having developers doing the packaging is an ideal situation. I often hear developers complaining about the multitude of GNU/Linux distros because they think it's somehow their responsibility to provide binaries. It's not. The role of the upstream developer is to make their build system easy to use so that other people (like distro maintainers, but also just "regular" users) can compile from source witho…

The problem is, my experience is "use autotools" and "don't package third party dependencies" make my software much harder for my users to build, and distributions are going to generally have out of date versions.

I'm not saying packaging is easy, and I do try to make it friendly for distributions, but don't pretend that doesn't make it worse for general users in the process.

Re: 20 years as a Debian maintainer

#32
post #27

Thank you for all your work. I installed Debian for the first time almost 13 years ago and have enjoyed the "Debian way" every second. But as the saying goes, all good things must come to an end. Due to various decisions by the Debian community, Debian Wheezy will be the last version I'm going to install and for the last few years I have been in the proccess of migrating thousands of servers away from Debian.

What are you migrating to, if you don't mind my asking?

FreeBSD, so the migration is not just away from Debian but also Linux. Of course problems always arise in such operations, but in general we have been very happy with the change, and I'm just as excited about FreeBSD as I was with Debian before.

Re: 20 years as a Debian maintainer

#34

Earlier quoted context omitted.

I don't think having developers doing the packaging is an ideal situation. I often hear developers complaining about the multitude of GNU/Linux distros because they think it's somehow their responsibility to provide binaries. It's not. The role of the upstream developer is to make their build system easy to use so that other people (like distro maintainers, but also just "regular" users) can compile from source witho…

The problem is, my experience is "use autotools" and "don't package third party dependencies" make my software much harder for my users to build, and distributions are going to generally have out of date versions. I'm not saying packaging is easy, and I do try to make it friendly for distributions, but don't pretend that doesn't make it worse for general users in the process.

It absolutely does not make it worse for general users in the process. The whole point is to help the user! I'm not saying there aren't problems on the distro side. Distributions like Debian do have the problem of moving much too slowly, and apt and the other "imperative" package managers are severely flawed, but the basic best practices I aligned make things better for all users.

And I'm not saying that you should never provide some prebuilt binary to your users if their distro is lagging behind. And if you really feel the need to bundle third-party libs then just make sure there are configure switches that can be flipped so that system libs are used instead. The best thing for users is for them to be able to get all of their software from their distro, and that requires distros and upstreams to each do their part.

Re: 20 years as a Debian maintainer

#35

Earlier quoted context omitted.

I don't think having developers doing the packaging is an ideal situation. I often hear developers complaining about the multitude of GNU/Linux distros because they think it's somehow their responsibility to provide binaries. It's not. The role of the upstream developer is to make their build system easy to use so that other people (like distro maintainers, but also just "regular" users) can compile from source witho…

The problem is, my experience is "use autotools" and "don't package third party dependencies" make my software much harder for my users to build, and distributions are going to generally have out of date versions. I'm not saying packaging is easy, and I do try to make it friendly for distributions, but don't pretend that doesn't make it worse for general users in the process.

You don't have to use autotools, but it makes doing the right thing easy. If you want to use CMake (I much prefer it myself!) just make sure you use pkg-config, same with scons or whatever. These are all included in Fedora's (my distro of choice) package collection and there's no trouble using them to build.

But please, if you decide to bundle third party libraries make sure you can build without them and use ones provided by the system instead. It's a political nightmare to include packages with bundled libraries because it makes security updates a huge headache since we can't simply rely on Anitya (https://release-monitoring.org/distro/Fedora/) to send us notifications that a new release of the library is available, not to mention the extra work of actually updating the bundled library once we do find out an update has been published.

Re: 20 years as a Debian maintainer

#37
post #10

Earlier quoted context omitted.

Sorry, I meant to write AppImage not flatpak. The point was that a lot of packaging would be done by the devs, allowing minutes maintainers to so more important stuff.

I don't think having developers doing the packaging is an ideal situation. I often hear developers complaining about the multitude of GNU/Linux distros because they think it's somehow their responsibility to provide binaries. It's not. The role of the upstream developer is to make their build system easy to use so that other people (like distro maintainers, but also just "regular" users) can compile from source witho…

> tl;dr - Make your software easy to build, don't just package up a mess.

You've pretty much hit the nail on the head. You forgot one additional bit though, please for the love of god don't have a crazy web of dependencies.

I see a lot of Node and Ruby apps online that I think would be incredibly useful in the Fedora package collection and have considered contributing them on more than once occasion. What always stops me is the 50+ dependent NPM packages or Gems they require that aren't already packaged by someone else.

The incredibly annoying part is most of these packages provide minimal functionality that you could have just implemented yourself, or that shouldn't in turn need another 3-10 transitive dependencies of their own. I get that not re-inventing the wheel is generally a good idea, but please try to pick your dependencies wisely if you want to see a distribution include your package - because a volunteer maintainer likely doesn't want to be responsible for your package + a dozen or more dependencies if they can avoid it.

Re: 20 years as a Debian maintainer

#38
post #27

Thank you for all your work. I installed Debian for the first time almost 13 years ago and have enjoyed the "Debian way" every second. But as the saying goes, all good things must come to an end. Due to various decisions by the Debian community, Debian Wheezy will be the last version I'm going to install and for the last few years I have been in the proccess of migrating thousands of servers away from Debian.

Mind if I ask what, in particular, is making you move?

Re: 20 years as a Debian maintainer

#39
post #27

Thank you for all your work. I installed Debian for the first time almost 13 years ago and have enjoyed the "Debian way" every second. But as the saying goes, all good things must come to an end. Due to various decisions by the Debian community, Debian Wheezy will be the last version I'm going to install and for the last few years I have been in the proccess of migrating thousands of servers away from Debian.

Mind if I ask what, in particular, is making you move?

I'm not rxlim, but considering that the release after Wheezy - Jessie - introduced systemd as the default init systemd, it's not hard to guess.

Re: 20 years as a Debian maintainer

#40
post #11

Earlier quoted context omitted.

Packaging is a complicated task and isn't as automatable as you'd think, It is important to consider how changes impact other tools. AppImage depends on maintainers too. Consider for example how appimage recipes depend on wget and bash and thusly openssl and libidn and glibc and libdl and git too, which brings with it libz and, and, and ... PS: Thank you, Riku. I never understood the sheer amount of effort involved i…

It can be easy for certain kinds of software: https://wiki.debian.org/AutomaticPackagingTools https://manpages.debian.org/man/1/dh_auto_configure https://manpages.debian.org/man/1/dh_auto_build https://manpages.debian.org/man/1/dh_auto_install

What I find complicated about Debian packaging is not how to use the tools and how to arrange the package, although that is certainly complicated, but not intractable. What I don't understand is once you have a package, why it is such a long and complicated process to get it into Debian.

You can't just upload it and forget, you have to sign up and become associated with that work, you have distribute your keys and get other people to trust you, you have to make a bug and file the package against that bug, etc. There is this whole social dynamic within Debian that I just don't understand at all.

If it was more like software development; make the package, git commit, push, post it to software like reddit and have people approve (upvote) it, then I'd be a maintainer already. Instead there's this whole process behind becoming a maintainer, finding a "mentor" etc, that for years I've just found to be a complete roadblock.

Post reply on HN