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

51–60 of 96 posts

Re: Maintainers Matter: The case against upstream packaging

#51

Post by jcastro »

gkya wrote: post #33
rodgerd wrote: post #16

Earlier quoted context omitted.

> An OS that has to release a version that'll be stable for the coming five years simply cannot provide bleeding edge packages. Wanting software more than every five years is hardly "bleeding edge".

If what you have is fine and works, why want new software? And if you want more frequent updates, you can (a) use a faster-moving branch, which BTW Debian and Ubuntu have; or (b) switch to an OS that provides you with more recent software, e.g. Arch Linux, Manjaro, Gentoo (? not that sure about this last one). Declaring sth. stable takes time, especially if you also incorporate new stuff into it. Even after five year…

I don't want to switch to ubuntu-devel or sid just to get a new version of VLC.

I just did a `snap install vlc` and got a recent version of vlc without having to upgrade my entire operating system.

Re: Maintainers Matter: The case against upstream packaging

#52

Post by vacri »

guardiangod wrote: post #11

Preface: 1. I use Arch Linux for my desktop and I like it. 2. I hate docker's repository systems (and other upstream packaging) But this article writer sure is putting the maintainers on a pedestal. More fundamentally, the maintainer is the primary line of defence and interaction between users and developers. Maintainers shield developers from uninformed users, allowing the devs to write software with less support ov…

While I'm more on jwz's side in the xscreensaver issue, it's a fair bit more complex that the way you're presenting it.

You're also missing the forest for the trees - if no-one maintained xscreensaver packages for distros, then there would be considerably fewer installs of it. Centralised package management is a very powerful feature, and without it, you're reduced to the Windows style of installing software: hunt around on the web for it, try and figure out if you're getting it from the official repo, try and figure out if the download is trustworthly, install it separately, hope it doesn't sideload malware, then maintain it personally as time goes on, and maybe even suffer every second tool having it's own self-updating service phoning home and nagging you (plus you may not even be able to easily uninstall the software if the author didn't offer that option). It's easy to do that for just one bit of software, but it's a real chore to do it for all your software.

Re: Maintainers Matter: The case against upstream packaging

#53

Post by vacri »

rodgerd wrote: post #30
johnny22 wrote: post #27

Earlier quoted context omitted.

that's not the kind of bundling people are talking about.

Did you even read the article? That's exactly the kind of thing the author claims distribution maintainers protect users from.

"This is why Linux doesn't have spyware, doesn't come with browser toolbars, doesn't bundle limited trials, doesn't nag you to purchase and doesn't pummel you with advertising."

The shopping lens was openly added as a marketed feature, and could be turned off with one action. You could, I suppose, class it as spyware, but it wasn't surreptitiously sideloaded - it was touted as a default feature. It didn't alter the browser, wasn't limited run, didn't nag you, and while I didn't use it much, it could hardly be called 'pummelling with advertising'.

It was an openly-acknowledged experiment that failed, and was removed.

Re: Maintainers Matter: The case against upstream packaging

#54

Post by mercurial »

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…

As a happy nixos user, I have to say that it's conceptually great, but that right now, the management tools are abysmal. Not only are the command line utilities unintuitive to use and pretty slow, but there is simply no graphical frontend, which means that I'm unable to switch family members to it.

Re: Maintainers Matter: The case against upstream packaging

#55

Post by Santosh83 »

vacri wrote: post #52
guardiangod wrote: post #11

Preface: 1. I use Arch Linux for my desktop and I like it. 2. I hate docker's repository systems (and other upstream packaging) But this article writer sure is putting the maintainers on a pedestal. More fundamentally, the maintainer is the primary line of defence and interaction between users and developers. Maintainers shield developers from uninformed users, allowing the devs to write software with less support ov…

While I'm more on jwz's side in the xscreensaver issue, it's a fair bit more complex that the way you're presenting it. You're also missing the forest for the trees - if no-one maintained xscreensaver packages for distros, then there would be considerably fewer installs of it. Centralised package management is a very powerful feature, and without it, you're reduced to the Windows style of installing software: hunt ar…

Why not get the benefit of both worlds but having centralised repositories for Snaps/Flatpaks? This way developers simply have to push their builds to it. Of course, also retain the traditional packaging model for much of the underlying system, and we seem to have hit a sweet spot between established practise and the anarchy of Windows land.

Re: Maintainers Matter: The case against upstream packaging

#56

Post by peterwwillis »

Yes, upstream vendors would love to have total control over how any user uses its software. But there is no guarantee that at least one of the vendors will not have a really shitty install or uninstall script which will do something like this:

  #!/bin/sh
  DIR=/home/$USER/ftp
  rm -rf $DIR
  rm -rf /home/guest
  adduser guest
.... assuming that /bin/sh is symlinked to bash (it isn't always), assuming $USER exists (it doesn't always), assuming the user 'guest' doesn't already exist with important files to keep... you really don't want to know how many ISVs actually have install scripts like this.

Users can still install ISV-packaged software in distros. But ISV packages typically hurt the system by removing things like vital dependency tracking information, or replace files that other packages provide, or won't be tracked for security patches, or will be installed into non-standard paths.

--

I have been a package maintainer for 6.. no wait 8... no, 9 Linux distributions. I have created thousands of packages (easily 10,000). I have maintained forked distributions for corporate use. I have also developed dozens of individual software projects which all were designed to be packaged by maintainers, and were adopted into Linux distributions by somebody else.

And i'm telling you: Anything other than maintainers packaging software is a fucking nightmare for everyone involved. We have a good system! Devs, make your software so it's easy to package. Maintainers, package it for your particular distro. Users, just use what's in the distro, OR follow the upstream's instructions on installing _at your peril_.

Re: Maintainers Matter: The case against upstream packaging

#57

Post by cyphar »

I cannot agree with this enough. I help package the container tools for openSUSE and SLE (I'm also an upstream maintainer of one of the tools as well, so I see both sides of the picture). But I personally am against ISVs making packages (especially "universal" ones) -- if they want to provide a container deployment method then provide the Dockerfile so people can build and curate it themselves.

It's really frustrating when upstream turns around and says "actually, we provide packages -- not you". In fact, we've had cases where a certain project suggested that a reasonable compromise would be that we change the name of the package in our distribution to "reduce confusion to users". Wat.

However, I do understand their point somewhat. If you have users pinging your issue tracker and they're using distro-supplied packages, then you are getting a lot of noise. But the right way of reporting bugs is to complain to your distribution (we actually live and breathe the distro you're using!) and I feel like upstream projects should make this communication model more clear rather than complaining to distros about users submitting bugs in the wrong place.

EDIT: Thanks for the SUSE shoutout! OBS is pretty cool and the people developing it are pretty cool people too.

Re: Maintainers Matter: The case against upstream packaging

#58

Post by cyphar »

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?

SUSE's OBS is in my biased opinion (I work at SUSE), probably one of the better ways of solving this problem for ISVs. You don't need a build infrastructure, you can get feedback from distribution maintainers and submission to the main distribution is surprisingly painless. Actually you can build packages for non-SUSE distributions on OBS as well, so it's even more versatile than just the openSUSE community's distributions.

Re: Maintainers Matter: The case against upstream packaging

#59

Post by cyphar »

coldtea wrote: post #22
tremon wrote: post #13

Earlier quoted context omitted.

The maintainers actively tried to sabotage his attempts to tell people to upgrade Ah, poor maintainer. Releasing software with a self-destruct timer is not an acceptable way to "tell people to upgrade".

No, but it's an effective way to say "f k you" to stubborn/lazy/backwards maintainers and/or distros who wont update.

Yes, those pesky stable distributions that prioritise bug fixes are clearly to blame. While it might be annoying for you (and me to some extent), some people actually need to have a stable system. If I was installing a GNU/Linux distro for a family member I would pick Debian or openSUSE Leap over a more rapidly updating distribution -- I just got burned by such a distro yesterday and I'm still reinstalling my machine.

Re: Maintainers Matter: The case against upstream packaging

#60

Post by cyphar »

wmf wrote: post #49
endgame wrote: post #46

Earlier quoted context omitted.

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.

GnuTLS is actually a good thing. OpenSSL has become a monoculture and there's a lot of good reasons to not use it (in addition, the license isn't GPL-compatible so it's a pain to link against in projects too).
Post reply on HN