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

Re: Maintainers Matter: The case against upstream packaging

#81

Post by gkya » Thu, Jun 16, 2016, 11:43 AM UTC

jcastro wrote: post #51

gkya wrote: post #33

Earlier quoted context omitted.

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.

That's OK. Nobody has an objection that you do it that way. It's just that there are acceptable flaws and shortcomings for some use cases, and some OSs care more about those.

Re: Maintainers Matter: The case against upstream packaging

#82

Post by davexunit » Thu, Jun 16, 2016, 1:14 PM 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.

As someone who works on Guile and Guix in good part because of their technical aspects and friendly community, this comes off as pretty insulting and ignorant.

Re: Maintainers Matter: The case against upstream packaging

#83

Post by digi_owl » Thu, Jun 16, 2016, 1:41 PM UTC

ploxiln wrote: post #65

drewcrawford wrote: post #43

Earlier quoted context omitted.

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

Yeah Chromium is a mess. To get and build the source you first have get the special tool set they use from their git repo.

Re: Maintainers Matter: The case against upstream packaging

#84

Post by jjnoakes » Thu, Jun 16, 2016, 2:34 PM UTC

Sanddancer wrote: post #50

insanebits wrote: post #7

Earlier quoted context omitted.

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

It's about trade-offs. There's no magic bullet (surprise!).

For example, some folks hate the Windows way because it has drawbacks like a different installation look/feel/process for each application, there's no automatic updates (unless the application has it built-in, which most don't), there's no automatic dependencies (so each app installer has to bundle its own versions of things, which also don't auto-update), there's no single place to go to look for a program that does something you need, automated installations are hard, inconsistent, or non-existent, security issues are harder to deal with (some image library issues from many years ago are probably still in the wild, bundled into some old version of some application), ...

Please keep in mind that "just silly" is just perspective and priorities.

Re: Maintainers Matter: The case against upstream packaging

#85

Post by mercurial » Thu, Jun 16, 2016, 3:01 PM UTC

roblabla wrote: post #74

mercurial wrote: post #54

Earlier quoted context omitted.

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.

Your complaints have been heard, and there are a lot of efforts to address them :) There's currently an effort to make the command line utilities easier to use[0]. There's also an effort to bring PackageKit to NixOS, which should make a few GUI package managers work[1]. [0]: https://github.com/NixOS/nix/issues/779 [1]: https://github.com/NixOS/nix/issues/233

That's really good to hear, I'm looking forward to it.

Re: Maintainers Matter: The case against upstream packaging

#86

Post by digi_owl » Thu, Jun 16, 2016, 3:53 PM UTC

tiziano88 wrote: post #25

Personally I think Nix ( https://nixos.org/nix/ ) does this right: packages are easy to install and upgrade for users, and developers and maintainers can easily create and update them. And if someone does not like the default collection of packages, it is as easy as starting one from scratch, or forking the existing one on GitHub, but at least it doesn't require reinventing the entire system.

Pretty much.

The base problem is not ISVs or maintainers. But that the rigidity of the package managers force maintainers to either use one version of a lib for the duration of the distro version, or play musical chairs with the package names to get around conflicts.

Either option makes it hard for third parties to produce packages.

The likes of Nix allows multiple versions of a packages to exist side by side, and ensures that each program gets the version it wants.

This allows a third party package to request a newer version of a lib than the distro provides, as it will not conflict with the distro provided packages while retaining the naming scheme.

Re: Maintainers Matter: The case against upstream packaging

#87

Post by vetinari » Thu, Jun 16, 2016, 5:02 PM UTC

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…

Atomic actually solves somewhat different problem as you think.

It uses rpm-ostree[0] as a basis "to bring together a hybrid of image-like upgrade features (reliable replication, atomicity), with package-like flexibility (introspecting trees to find package sets, package layering, partial live updates)".

rpm-ostree itself is a layer above OSTree[1], which describes itself as a "git for operating system binaries" - "OSTree is a tool for managing bootable, immutable, versioned filesystem trees."

Yes, it can run docker images; but so does CoreOS or any normal distribution and they are not based on rpm-ostree at all.

[0] https://github.com/projectatomic/rpm-ostree [1]https://wiki.gnome.org/Projects/OSTree

Re: Maintainers Matter: The case against upstream packaging

#88

Post by coldtea » Thu, Jun 16, 2016, 5:05 PM UTC

cyphar wrote: post #59

coldtea wrote: post #22

Earlier quoted context omitted.

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…

>While it might be annoying for you (and me to some extent), some people actually need to have a stable system.

If desktop packages like the XScreensaver is what makes your system unstable, then you have worse problems...

Re: Maintainers Matter: The case against upstream packaging

#89

Post by lamontcg » Thu, Jun 16, 2016, 7:22 PM UTC

Unless I'm misunderstanding, I think Chef has been doing this for years with omnibus packages.

The reason we did this is that we had to support RHEL5/6 and old Solaris and AIX distros.

We struggled for several years (and I personally struggled for at least a year) with supporting RHEL5 and it simply failed. That distro came with ruby-1.8.5 and upgrading it to even 1.8.7 was a major PITA. The ruby-1.9.2 in RHEL6 was also buggy and crashy and segfaulty and we didn't remotely have the resources to attempt to debug it and patch it for RedHat.

The reality is that we just wouldn't have been able to support those old distros at all.

I think there's a myth here that the human resources to support packaging and debugging apps against distro-supplied libraries and supporting packages magically appears out of thin air. It does not. As those supporting libraries age it consumes more and more time to support "back porting" onto aging versions of frameworks, which cannot be upgraded in the distro because of compatibility with other apps. That creates a large amount of serious shit work (seriously, nobody enjoys doing that) and open source doesn't make it magically appear.

I also think there's a misconception that user's have chosen to use those versions of software. Largely they've chosen that because they need the compatibility with a large body of their own custom in-house software and their internal porting effort is costly in time and labor. Largely they don't care if you install an upgraded version of supporting libraries so long as it doesn't impact any other running software and its contained.

For another example of software that has been doing this for years, check out vagrant.

Admittedly, there's issues with this since openssl vulnerabilities require the release of new software versions to upgrade the embedded version.

Re: Maintainers Matter: The case against upstream packaging

#90

Post by dmacvicar » Thu, Jun 16, 2016, 8:51 PM UTC

I don't see the contradiction between Flatpack/xdg-app and keeping packages downstream. http://openbuildservice.org/ could end building xdg-app images in addition to rpm, deb, Arch and images it already builds. Why not?

That would keep security, reviews & processes while stopping the nonsense of requiring root, global state & single versions rpm/deb enforce to the user.