Maintainers Matter: The case against upstream packaging • Hacker News Board

Re: Maintainers Matter: The case against upstream packaging

#61

Post by cyphar » Thu, Jun 16, 2016, 5:40 AM UTC

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.

Who said you have to upgrade a whole machine when updating a package? Literally every package manager worth its salt allows you to upgrade a single package. And you can usually specify what version you want too.

Yes, ISVs have the right o package their software. But as someone who is both a maintainer of a free software project and packages software for a distribution, I can tell you that I definitely do _not_ want to deal with packaging for every distribution (especially if it's some magical "universal" package). I've used enough distributions to recognise that they all have differences that you really can't "just package for every distribution with one setup".

Re: Maintainers Matter: The case against upstream packaging

#62

Post by cyphar » Thu, Jun 16, 2016, 5:43 AM UTC

rodgerd wrote: post #15

Linux has never had crap bundled? I guess the author forgot Canonical's "shopping lens" debacle, which was fully as sleazy as any ask toolbar bundling nonsense.

And the reaction from the community was so fierce that they stopped. That was the second point the author was making. I don't recommend Ubuntu any more because of unethical actions like that, and I know quite a few people who do the same.

Re: Maintainers Matter: The case against upstream packaging

#63

Post by vacri » Thu, Jun 16, 2016, 6:05 AM UTC

Santosh83 wrote: post #55

vacri wrote: post #52

Earlier quoted context omitted.

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.

Sure. I'm a pragmatist - if that would work, I'd be happy. One major problem is fragmentation/network effects though - you'd need to get enough developers onboard to make something effectively the 'default' userspace packaging system. Major distros already have a big NIH problem with system packaging, every one having it's own system.

Packaging is a difficult problem - the 80% use case is easy to solve, but the edge cases really require elegant forethought. It also seems that every distro has a different idea of what that 20% is...

Re: Maintainers Matter: The case against upstream packaging

#64

Post by icebraining » Thu, Jun 16, 2016, 6:07 AM UTC

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.

Gnash, really? What other open alternative to Adobe's player would you recommend? For example, Gnash is the only way to get Flash support on the Raspberry Pi - is that not valuable?

Re: Maintainers Matter: The case against upstream packaging

#65

Post by ploxiln » Thu, Jun 16, 2016, 6:19 AM UTC

drewcrawford wrote: post #43

jsizz wrote: post #28

Earlier quoted context omitted.

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

Chromium only became compatible with linux in 2010. https://googleblog.blogspot.com/2009/12/google-chrome-for-ho...

Arch Linux packaging files have source history going back to then as well.

Chromium is also an example of a package that took a long time to appear in other distros, because it's really written with the app mindset. It copies and incompatibly customizes most of its dependencies. No one would consider that a great idea for ongoing maintenance and security patching for a typical project, but of course this is a google product-oriented thing with nearly a thousand well-above-average-skill developers assigned, so it's not a problem for them to manage surprisingly huge volumes of code and changes.

Web browsers like Chromium are also a good example of the kind of modern software which doesn't work well with the debian release model, because it's "unsupported and practically broken" in like half a year. That's not true for the "make" utility, or for gimp or inkscape or libreoffice or audacious or countless other useful applications and tools which are not browsers.

I really don't like the fact that modern browsers are a crazy-train and there's just no getting off it.

Re: Maintainers Matter: The case against upstream packaging

#66

Post by legulere » Thu, Jun 16, 2016, 6:34 AM UTC

The case against distro packaging:

- Desktop Linux has a small user base. Further splitting it up with different packages for each distribution makes it further a non-target.

- You can only install software cleanly that is packaged by your distributor. No distributor packages software that costs money. Many distributors try to prevent you from installing software with licenses they don't approve.

- If your user is using a stable distribution they will have old software. The distribution might only push bug fixes if they are security related. Users will report bugs that are already fixed.

- Maintainers often have no idea what they're doing, because they aren't working on the project and there are rarely other developers that check their patches. Worst case this leads to something like the Debian random number generator bug.

Distribution packaging for user facing programs has large drawbacks with marginal benefits, which can be mostly broke down to the not invented here syndrome.

Re: Maintainers Matter: The case against upstream packaging

#67

Post by keithpeter » Thu, Jun 16, 2016, 8:38 AM UTC

mercurial wrote: post #54

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.

Do you find a good range of packages available?

I'm downloading the live image to have a look/play

Re: Maintainers Matter: The case against upstream packaging

#68

Post by rekado » Thu, Jun 16, 2016, 8:59 AM UTC

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?"

I wouldn't call it a schism; this sounds much too negative. They are different implementations of the same idea. Nix uses an external DSL, Guix an embedded DSL (using Guile Scheme for everything). The projects are not competing against one another. Problems that are solved to make software packageable in Nix benefit Guix and vice versa.

As a Schemer and GNU person it was easy for me to pick Guix. I've been contributing to Guix for a few years now. I find the tooling of Guix to be more accessible and more hackable.

In my experience when packaging Java for Guix it seems to me that Guix is a little more principled, where Nix would more readily accept binaries for bootstrapping (e.g. prebuilt jars).

Considering how different functional package management is compared to the alternatives I think that novices could pick one or the other; once they are used to functional package management they can better make a decision to switch to another implementation.

For bioinformatics software, though, Guix is far ahead. It's used at our bioinfo institute and in big projects like GeneNetwork.

Re: Maintainers Matter: The case against upstream packaging

#69

Post by rekado » Thu, Jun 16, 2016, 9:13 AM UTC

gkya wrote: post #14

stormbrew wrote: post #5

This seems like an overly optimistic view of the abilities and resources of distribution package maintainers. The reality is that no matter how hard they try, it's almost impossible for them to keep up, and even with a non-LTS Ubuntu release train I still need to use a number of PPAs and other mechanisms of install to get some things I use on a daily basis. And that's with both Canonical and Debian's resources involv…

When you serve out an entire system for a group of diverse users with lots of installable programs, it's important to ensure that parts will work together. Especially in Unix where namespace clashes in /bin, /lib and /etc may cause serious problem for system administrators and users. Thus, every stable release has to ensure that none of provided software shall do nothing nasty. But with bleeding edge, you lose the co…

With functional package management (as in GNU Guix or Nix) you no longer have namespace clashes and packages can be added without too much concern for unrelated packages.

I find functional package management to be a vast improvement over the packaging situation --- unlike incarnations of the latest bundling/appification trend such as Snappy or Docker.

Re: Maintainers Matter: The case against upstream packaging

#70

Post by majewsky » Thu, Jun 16, 2016, 9:17 AM UTC

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…

> But do we really believe 1/38th of a person is judiciously considering how to overrule upstream's decisions, attentively investigating user bug reports, and so on?

It looks much worse than it is, because most packages are really boring from a maintainer perspective.

For example, KDE releases a hundred or so applications. Some of them are probably very interesting to package, but for most packages, `cmake && make && make install` is just fine (maybe plus a certain KDE integration macro that your packaging tool already carries).