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

Re: Maintainers Matter: The case against upstream packaging

#71

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

mtgx wrote: post #10

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.

This type of attitude completely ignores regular desktop users who may one day want to use Linux over Windows.

A regular desktop user does not want bleeding-edge software; he will do just fine with last year's VLC. (A notable exception being the web browser.)

The priority for a regular desktop user is a nicely integrated system, and that is something that ISVs cannot deliver because they don't know what to integrate with.

Re: Maintainers Matter: The case against upstream packaging

#72

Post by rekado » Thu, Jun 16, 2016, 9:46 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.

You don't need to upgrade everything just to upgrade a single package. With traditional GNU+Linux distributions this isn't always quite true, because it's hard to install different variants side-by-side.

With functional package management every application and library gets its own namespace. Installing something is a matter of picking individual items from their own namespaces and creating a profile, the union of all outputs of all packages that are to be installed.

This makes it possible for users to install not only different major versions for selected applications but even variants of the same package (e.g. different configuration flags or different compiler).

At the bioinformatics institute we are using this to provide scientific software to cluster users. With Guix, users can create custom variants with very little effort without affecting the system state or other people's software profiles.

There is still a lot that can be done by improving package management systems. Giving up by going the route of appification (like it's done with Snappy or when Docker is abused as a packaging tool) is a bad choice, in my opinion.

Re: Maintainers Matter: The case against upstream packaging

#73

Post by roblabla » Thu, Jun 16, 2016, 9:51 AM UTC

keithpeter wrote: post #67

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.

Do you find a good range of packages available? I'm downloading the live image to have a look/play

Most of the "standard" packages are already in it, and those that aren't are fairly easy to add in. I created and maintain the Matrix.org Synapse package, for instance, and it was a breeze to package myself, even without any prior experience of nixos packaging.

Re: Maintainers Matter: The case against upstream packaging

#74

Post by roblabla » Thu, Jun 16, 2016, 9:57 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.

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

Re: Maintainers Matter: The case against upstream packaging

#75

Post by roblabla » Thu, Jun 16, 2016, 10:00 AM UTC

rekado wrote: post #68

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

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

The thing is, they are competing for package maintainers and users. A Nix package can't be natively used by Guix, and vice-versa, so a package have to be written for both.

Re: Maintainers Matter: The case against upstream packaging

#76

Post by digi_owl » Thu, Jun 16, 2016, 10:13 AM UTC

ashitlerferad wrote: post #44

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.

To be fair, Nix takes it one step further.

In Nix, if you recompile the same version lib with new options, it will get a new branch in the Nix tree. While it will replace the existing one in Gobolinux.

I think there is a option for the Gobolinux Compile tool to behave more like Nix, but i have not explored its behavior much.

Re: Maintainers Matter: The case against upstream packaging

#77

Post by rekado » Thu, Jun 16, 2016, 10:13 AM 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.

I second this. I'm using Guix both privately and at work to provide bioinformatics software on our cluster. We have an additional repository of package variants for things that shouldn't be part of the default collection.

Writing package expressions is usually very simple, especially since we can use package importers to automatically generate and update them.

Re: Maintainers Matter: The case against upstream packaging

#78

Post by digi_owl » Thu, Jun 16, 2016, 10:15 AM UTC

Avshalom wrote: post #47

endgame wrote: post #46

Earlier quoted context omitted.

Is there a good heuristic to answer this question?

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

Heh, my thinking basically. As Guix is a GNU project, it adheres to FSF definitions of freedom. That means there will be no proprietary drivers or similar in the official repositories.

Re: Maintainers Matter: The case against upstream packaging

#79

Post by rekado » Thu, Jun 16, 2016, 10:39 AM UTC

digi_owl wrote: post #78

Avshalom wrote: post #47

Earlier quoted context omitted.

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

Heh, my thinking basically. As Guix is a GNU project, it adheres to FSF definitions of freedom. That means there will be no proprietary drivers or similar in the official repositories.

This is true. We offer deblobbed Linux (linux-libre) by default.

However, it is very simple to customise packages, including the kernel package, e.g. to apply patches, use different sources, or to exercise your right to disagree with the Linux libre upstream on what blobs should be deleted from the kernel.

That said, I consider freedom by default a feature and it works very well on most of the hardware I use (an exception is an on-board Radeon graphics chip in a desktop machine I don't use much).

Creating package variants is almost trivial; it's certainly no harder than, say, customising Emacs. Guix blurs the lines between user and maintainer, so using custom package definitions is a supported use-case. At work even our scientist users create custom packages in case they are not available in Guix upstream yet.

Re: Maintainers Matter: The case against upstream packaging

#80

Post by digi_owl » Thu, Jun 16, 2016, 10:47 AM UTC

rekado wrote: post #79

digi_owl wrote: post #78

Earlier quoted context omitted.

Heh, my thinking basically. As Guix is a GNU project, it adheres to FSF definitions of freedom. That means there will be no proprietary drivers or similar in the official repositories.

This is true. We offer deblobbed Linux (linux-libre) by default. However, it is very simple to customise packages, including the kernel package, e.g. to apply patches, use different sources, or to exercise your right to disagree with the Linux libre upstream on what blobs should be deleted from the kernel. That said, I consider freedom by default a feature and it works very well on most of the hardware I use (an exce…

Sounds very similar to my experience with Gobolinux. If the source is packaged sanely (proper support for --prefix or equivalent) a user can roll up a recipe ready for Compile with a single command and a url to the source needed.