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

Maintainers Matter: The case against upstream packaging

kmkeen.com

Post reply on HN
Print view View original

41–50 of 96 posts

Re: Maintainers Matter: The case against upstream packaging

#41

Post by keenerd »

kalessin wrote: post #37
keenerd wrote: post #24

Earlier quoted context omitted.

I presume you mean lightsd. Nifty stuff. What do you think of Suse's OBS? I believe you're squarely in its target audience. And hats off to you for going the extra mile for your project! Your PKGBUILD even looks quite good. Would you like some assistance in writing a -git pkgbuild for people who want to try the absolute newest commit?

Thank you! Yes, I was referring to my work on lightsd. I didn't know about Suse's OBS until this thread, I guess I need to look into it. I have been building my own CI/CD pipeline on top of Buildbot so far. It's a PITA, but leaves a lot of room for creativity, hopefully it will be rewarding down the road. I don't know about the -git thing for PKGBUILD, what's the syntax/documentation?

It is briefly mentioned in the manpage, https://www.archlinux.org/pacman/PKGBUILD.5.html, but basically a pkgbuild can use a git repo as a source directly. Here's an example:

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=pacma...

Compare it to pacman's release-based pkgbuild:

https://git.archlinux.org/svntogit/packages.git/tree/trunk/P...

The major differences are the "git" url in the sources, the provides/conflicts metadata and the dynamic pkgver() function.

Re: Maintainers Matter: The case against upstream packaging

#42

Post by kalessin »

keenerd wrote: post #41
kalessin wrote: post #37

Earlier quoted context omitted.

Thank you! Yes, I was referring to my work on lightsd. I didn't know about Suse's OBS until this thread, I guess I need to look into it. I have been building my own CI/CD pipeline on top of Buildbot so far. It's a PITA, but leaves a lot of room for creativity, hopefully it will be rewarding down the road. I don't know about the -git thing for PKGBUILD, what's the syntax/documentation?

It is briefly mentioned in the manpage, https://www.archlinux.org/pacman/PKGBUILD.5.html , but basically a pkgbuild can use a git repo as a source directly. Here's an example: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=pacma... Compare it to pacman's release-based pkgbuild: https://git.archlinux.org/svntogit/packages.git/tree/trunk/P... The major differences are the "git" url in the sources, the provides/…

Nice, maybe I'll consider this for dogfooding, thank you for the explanations!

Re: Maintainers Matter: The case against upstream packaging

#43

Post by drewcrawford »

jsizz wrote: post #28
drewcrawford wrote: post #12

I feel like this article is sort of attacking a straw man. > The promise: Sandboxing makes you immune to bad ISVs. The reality: It protects you from some things and not others. Well yeah, but the same could be said of maintainers. Maintainers let things through all the time, and sometimes they cause problems (hello, Debian weak keys). The reality is a bit complicated, and it boils down to something boring like: if th…

> sometimes they cause problems (hello, Debian weak keys). > until recently nobody was packaging Chromium for example. To name one example, SlackBuilds.org has had Chromium since 2010, although admittedly that's not so long ago as the Debian weak key cockup, which was 2006. Maybe your examples could use an upgrade to the latest stable version.

Chromium may have been packaged in 2010, but it was released three years before. The Debian weak keys "cockup" may have been created in 2006, but it was discovered two years later. Maintainers had long windows of time to add value. Did they?

I don't mean anything personal by it. If I was maintaining 38 packages on my nights and weekends I'd do a bad job too.

But examples don't go out of date unless you present some force that takes 30k unmaintainable packages and turns them into 50k maintainable packages. What specific advance in software maintenance do you believe improved the art of software maintenance by an OOM?

But if you want to talk recent examples, we could talk about how nobody's packaging Swift.

Re: Maintainers Matter: The case against upstream packaging

#44

Post by ashitlerferad »

davexunit wrote: post #3

I agree with a lot of this. GNU/Linux distros are going down a very dangerous path with Snappy, Docker, Flatpak, Atomic, etc. I think a lot of this is responding to the fact that traditional systems package managers are quite bad by today's standards. They are imperative (no atomic transactions), use global state (/usr), and require root privileges. Snappy and co. take the "fuck it, I'm out" approach of bundling the…

You're forgetting GoboLinux, which had these issues solved long before NixOS/Guix existed.

Re: Maintainers Matter: The case against upstream packaging

#45

Post by tobltobs »

ramblenode wrote: post #23
davexunit wrote: post #3

I agree with a lot of this. GNU/Linux distros are going down a very dangerous path with Snappy, Docker, Flatpak, Atomic, etc. I think a lot of this is responding to the fact that traditional systems package managers are quite bad by today's standards. They are imperative (no atomic transactions), use global state (/usr), and require root privileges. Snappy and co. take the "fuck it, I'm out" approach of bundling the…

Snappy, Docker et al. are the newest beasts in the evolution of packaging solutions. Nix and Guix decided evolution was too slow and to skip ahead an epoch or two.

Docker isn't a packaging solution. It is an excuse to avoid packaging.

Re: Maintainers Matter: The case against upstream packaging

#46

Post by endgame »

mwcampbell wrote: post #38
davexunit wrote: post #3

I agree with a lot of this. GNU/Linux distros are going down a very dangerous path with Snappy, Docker, Flatpak, Atomic, etc. I think a lot of this is responding to the fact that traditional systems package managers are quite bad by today's standards. They are imperative (no atomic transactions), use global state (/usr), and require root privileges. Snappy and co. take the "fuck it, I'm out" approach of bundling the…

I wonder if the Nix approach would be more popular if a schism (between Nix and Guix) hadn't developed so early. When you talk about Nix and Guix, a novice's natural first question is, "Which one do I use?"

Is there a good heuristic to answer this question?

Re: Maintainers Matter: The case against upstream packaging

#47

Post by Avshalom »

endgame wrote: post #46
mwcampbell wrote: post #38

Earlier quoted context omitted.

I wonder if the Nix approach would be more popular if a schism (between Nix and Guix) hadn't developed so early. When you talk about Nix and Guix, a novice's natural first question is, "Which one do I use?"

Is there a good heuristic to answer this question?

Nix until some intrepid souls set up a large supplemental non-free repo for guix

Re: Maintainers Matter: The case against upstream packaging

#48

Post by cathartes »

The author's point about "dogfooding" jumped out at me more than he probably intended, but that's probably because it's an aspect of Slackware's SlackBuilds repository (SBo) that I can't say enough about.

Quite often, SBos are maintained by folks who use (even depend) on the software they are responsible for. As such, well-tested and sanely configured software tends to be highly valued by maintainers, and package responsibilities will commonly change hands when a maintainer no longer uses what (s)he's responsible for.

The mechanics of an SBo are also dead simple, making package review and modification by the user straightforward. This means that rolling your own package is straightforward, enabling you to easily become a "dogfooding" maintainer yourself for any package not already in the repo. Few distributions allow ordinary users to close the official package loop with anywhere near the ease--both technically and bureaucratically--that SBos do.

SBos are not the Perfect Package model by any means. But in terms of "dogfooding", ISVs and big distributions (especially Canonical) could stand to learn a few things from a relatively unstructured community of volunteers with a taste for the KISS principle.

Re: Maintainers Matter: The case against upstream packaging

#49

Post by wmf »

endgame wrote: post #46
mwcampbell wrote: post #38

Earlier quoted context omitted.

I wonder if the Nix approach would be more popular if a schism (between Nix and Guix) hadn't developed so early. When you talk about Nix and Guix, a novice's natural first question is, "Which one do I use?"

Is there a good heuristic to answer this question?

Some software is promoted on its merits and some software exists just "because it's GNU" (e.g. Hurd, Guile, Guix, gNewSense, GnuTLS, Shishi, GNUstep, Gnash, etc.). It's pretty safe to ignore the latter kind.

Re: Maintainers Matter: The case against upstream packaging

#50

Post by Sanddancer »

insanebits wrote: post #7
tacone wrote: post #6

Enough of this. People have the right to install last version of software easily without having to upgrade the whole server at once. ISV have the right to package their own software. If MongoDB is a commodity I can gladly stick to the distro version. If I'm developing something of more cutting edge I want and will install the latest version from the ISV repo.

Yes they can, there is nothing preventing them creating the package. But it shouldn't be a primary way of installing package. If you really need bleeding edge for development you can build it yourself.

Which is exactly why I've given up on desktop Unix. With Windows, instead of having to wait for the maintainers to declare a package worthy of their distribution, I can just run the vendor's installer, without any fuss or hassle. FreeBSD, IMO, gets packaging the most correct with separating user packages from the core distribution, but there are still times when they'll have an old version as well. Relying on a single app provider, be it apple or debian, is just silly.
Post reply on HN