Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

20 years as a Debian maintainer

suihkulokki.blogspot.com

Post reply on HN
Print view View original

51–60 of 126 posts

Re: 20 years as a Debian maintainer

#51

Post by davexunit »

nrclark wrote: post #44
davexunit wrote: post #22

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…

Got any advice for ways to bundle stuff written in Rust, Go, Ruby, or Node? All of these languages come with package-managers that encourage reusing packages from their respective ecosystems. I packaged a Github clone called Gogs (written in Go) for Debian/Ubuntu, complete with Lintian support. But I had to compromise on the 'rules' file and add a "get-orig-source" target that uses Go's package manager to grab all of…

There's no easy road. We need to convince upstream to change their ways. The proliferation of language-specific package managers is a problem that many people don't yet understand is a problem. I often get hostile reactions when I advocate for general-purpose systems package managers over language-specific ones.

In the meantime, we can use the information available in these language package managers to help bring that software to the systems package managers. How easy it is all depends on the language. If the language/package manager is sane and the build system isn't conflated with the package manager, we can make quick progress by writing importer scripts that automate most, but not all, of the work. Node, Go, and Java are utter nightmares for various reasons. Python is pretty good. Ruby is somewhat annoying but doable. It seems that Rust is decent but I haven't used it. All I know is that someone recently wrote a Crate package import for GNU Guix (the package manager I contribute to and recommend highly) that seems to work. [0]

[0] https://www.gnu.org/software/guix/manual/html_node/Invoking-...

Re: 20 years as a Debian maintainer

#52

Post by brennen »

radarsat1 wrote: post #40
BuuQu9hu wrote: post #21

Earlier quoted context omitted.

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 ge…

> You can't just upload it and forget

Leaving aside the specifics of Debian's tooling and social process (undeniably, these are arcane and complex), I suspect this has a lot to do with why Debian is such a reliable environment over time in a way that few software collections manage.

It would almost certainly be better if it were easier than it is to participate in Debian. I've thought about contributing for years, but I certainly haven't had the energy to clear those hurdles. On the other hand, there's something really important in the distance between typical modern software publication and packaging for an ecosystem like Debian.

I think we'd be a lot better off if more people were committed to the hard, tedious process stuff that renders software accessible to users, a good neighbor to other projects, and maintainable over the long term.

Re: 20 years as a Debian maintainer

#53

Post by suihkulokki »

rxlim wrote: post #28
jwilk wrote: post #2

Version that can be read without JS enabled: https://suihkulokki.blogspot.com/2017/01/20-years-of-being-d...

I cannot comprehend why on earth Javascript is required just to show some text. This must be the height of web design silliness.

I just switched to a simpler theme, I didn't realize the one I had chosen was so dependant on javascript.

Re: 20 years as a Debian maintainer

#55

Post by suihkulokki »

cixin wrote: post #3

In case the author reads this, and as I can't comment there: Thank you. Debian is an awesome and somewhat under-rated distribution. Being a maintainer always seems like a thankless and slightly forgotten role. Thanks for having the persistence to keep going so long.

Had I known the text would end up shared here, I'd surely spent more than 15min writing it! I'm hardly the most active contributor in Debian, but I guess that's part of how one can manage so long.

Re: 20 years as a Debian maintainer

#56

Post by irl_ »

vbernat wrote: post #30
irl_ wrote: post #16

Earlier quoted context omitted.

As a Debian Developer I often find myself throwing away the upstream Debian packaging and starting from scratch. It's not that it doesn't work but that it doesn't fit with Debian policy and so is not easily included or modified without basically starting from scratch anyway. In the cases (which happens more than you might think) where an upstream developer has actually got really good packaging, I've usually taken th…

Also, upstream may have different concerns. For example, they want to be built on various versions of the distribution while Debian will usually only target unstable. I am upstream for some of my packages and I don't provide the same debian/ directory upstream as I use for Debian.

Now that we have faster moving packages and especially where we have packages that depend on external systems (like cloud services), I think more and more Debian Developers need to be making use of backports to ensure that stable versions remain up to date.

I've heard time and time again that there are issues with Debian's version being out of date, but this doesn't have to be this way, at least not by policy. If there is a backport maintainer (doesn't even have to be the same person working on unstable) then the latest version can be installable within a stable system giving you the latest and greatest of the applications that need it with a stable base underneath.

Re: 20 years as a Debian maintainer

#57

Post by barrkel »

Z-Widwil wrote: post #50
SteveNuts wrote: post #41

Earlier quoted context omitted.

I went into systemd with an open mind, hoping the changes would be worthwhile to learn. I've come out the other end looking for alternatives... In the meantime I'll stick to an OS that uses init, and hope systemd get's better given enough time.

Having just set up a Debian server this weekend (Windows dev diving into Linux for the first time), can I ask what the main difference between init and systemd are? Mostly from a operational/security stand point.

Init-scripts are a bunch of file system conventions and shell scripts; it's an imperative way of bringing a system into a particular state (networking, services etc.). Init itself is the very first process the the OS executes; all processes in -nix are created by forking. When using init-scripts, init is extremely simple.

Systemd replaces init and uses a declarative approach for the system and its services, and the dependencies between the services (replacing init-scripts). Systemd is more complicated but can do more stuff, like initialize things concurrently. Functionality that used to be implemented in services themselves (e.g. restarting, recovery) is migrating into systemd, and systemd is acquiring more and more logic. Some people feel that this is contrary to the *nix philosophy and is not architecturally sound.

Operationally, instead of using shell scripts and symlinks designed to be sorted in a particular order (normally maintained using other tools), you use descriptions of how the service should start and what it depends on.

Security-wise, systemd is a bigger hairier ball, so it probably has bugs. But it also implements stuff once, whereas before implementations were distributed and of variable quality. So the variance in security level is probably lower with systemd, but depending on your mix of services, the mean may be higher or lower. And you don't get to control it.

Re: 20 years as a Debian maintainer

#58

Post by suihkulokki »

bostand wrote: post #7

Thanks Riku, debian has become an excellent distro thanks to the hard work of people like you. At the same time, it is sad to see how much work you guys need to do for things that should have been automated or done by the original developers... Let's hope AppImage changes that Edit: Changed flatpak to appimage

I wouldn't mind a large percentage of end user applications coming directly from upstream developers them self. However, I hope it doesn't take away end users ability hack/tinker/modify/rebuild the application installed from appimage/flatpak.

Already often a big part of Debian packaging work is making the software compile outside the developers personal enviroment without manual steps - or in the other end decoupling from the developers CI loop.

Re: 20 years as a Debian maintainer

#59

Post by jancsika »

davexunit wrote: post #22
bostand wrote: 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…

> - Don't bundle third-party dependencies. For security (and for better documentation of the true dependency graph) distros often must go through extra trouble to unbundle third-party libraries when present. Some project even add their own custom patches to their bundled source. Resist the urge to do this.

If any of the dependencies aren't currently packaged in Debian, how would one follow this guideline?

Re: 20 years as a Debian maintainer

#60

Post by opk »

AceJohnny2 wrote: post #46

A couple of weeks before they got accepted? Wow! I considered become a DD about 10 years ago, but a friend was going through the process and it took them over a year with at least one restart-from-scratch because the bureaucracy had been lost or something. > Regis NM did start somewhere in 2003. There was a period of him being on hold, in 2006 we did continue the process, which used some time, but most of the delay u…

I went through a similar experience with the NM process some ten years ago except I ended up giving up on the whole thing. After being told I absolutely had to answer a load of questions within a week for a week that happened to be very inconvenient, my answers then got completely ignored. I carried on maintaining the one package until a few years ago when I gave up because nobody would sponsor an upload until the freeze at which point I was being told I had to backport bug fixes to the old release. I actually ended up jumping to FreeBSD before the whole systemd mess hit and I've found it to have a friendlier community.
Post reply on HN