Guix: A New Package Manager & GNU Distribution

Quote:

---

Originally Posted by timofonic

But distribution developers are full of massively developed egos, fanaticism and hidden commercial interests.

---

Although not half as much as distro *fans*....

Quote:

---

Originally Posted by renox

Wrong, it isn't another package manager as it is based on NixOS's package manager, only changing its configuration language.
NixOS's package manager has nice properties, unfortunately they also made a big error in naming the installed package "<big series of number>-package name" instead of "package name-<big series of number>"
which makes listing the directory unreadable..

---

You aren't supposed to do listings of /nix/store/ and I don't see much reason in it. There are often too many entries to list anyway, for example on my system I have over 29 thousand entries there (I'm a bit conservative when doing GC). Moreover, you can always use wildcards like /nix/store/*-firefox-*

Quote:

---

Originally Posted by timofonic

Cats are difficult felines sometimes, but they end learning how to live at the same place. Those developers are like doing the same to a bunch of religious fanaticals, they'll end killing each other.

But distribution developers are full of massively developed egos, fanaticism and hidden commercial interests.

---

That's problem is that the two first gets in the way of their hidden commercial interests. Unless there are compatibility between Linux distributions it will be impossible for Linux to conquer the desktop. And in turn this means no profit.

What I would suggest is a meta-standard that defines package spec:s in a independent way, so that the same spec:s can make packages for the various package managers and repository formats.

Then I would suggest building something like blastwave that gets installed into /somting like blastwave has /csw. That would make it easier to make something distribution-independent and coherent among platforms.

Quote:

---

Originally Posted by mateli

What I would suggest is a meta-standard that defines package spec:s in a independent way, so that the same spec:s can make packages for the various package managers and repository formats.

---

That's not so easy as it may seem (that's what XKCD illustrates). For example in NixOS we deal with the problem that to support transparent reliable updates you can't have libraries on standard paths but on some configure-time paths (no LSB, etc. !). Otherwise you can't atomically switch between two versions in one filesystem tree (which everyone want but almost none have).

Most packages can handle arbitrary paths or can be easily patched to do so (from our experience), but most packages systems IMHO count on standard paths. So it is IMHO possible to create this meta-standard but it will have to support all similar features, which will be a lot if we want to catch every small distro. I just currently can't imagine mainstream distro packagers supporting features that they don't need/use.

Upstream-based solutions to this seem to work better. We just need a tool that can from one reasonable description build packages at least for mainstream distros. But IMHO we have such, e.g. http://openbuildservice.org/ Nix can do this as well, but it isn't used much, as it is nonsense to maintain packages for other distros when they do it separately anyway (for most packages that we have).

Quote:

---

Originally Posted by vcunat

You aren't supposed to do listings of /nix/store/ and I don't see much reason in it. There are often too many entries to list anyway, for example on my system I have over 29 thousand entries there (I'm a bit conservative when doing GC). Moreover, you can always use wildcards like /nix/store/*-firefox-*

---

the Unix principle of 'everything is a file' has one very interesting property of making the system discoverable, naming files with random number goes against this which is bad,
they already made it 'more discoverable' by putting the package name, but adding it at the end instead of the at the beginning *is* a mistake as it makes RE more complicated, prevents autocompletion.

Quote:

---

Originally Posted by Nille

unprivileged package management
Does that mean that in can Install an Package as an User to my Own Applications?

---

You can do that with APT too (and I suppose also with rpm), although you will probably have to do a lot of manual configuration for that...

Quote:

---

Originally Posted by renox

the Unix principle of 'everything is a file' has one very interesting property of making the system discoverable, naming files with random number goes against this which is bad,
they already made it 'more discoverable' by putting the package name, but adding it at the end instead of the at the beginning *is* a mistake as it makes RE more complicated, prevents autocompletion.

---

Technically, it only prevents legacy autocompletion; many modern shells allow extended/customizable autocompletion.

And maybe one of the NixOS developers can tell us whether this was done on purpose (and why) or not?

Quote:

---

Originally Posted by JanC

although you will probably have to do a lot of manual configuration for that...

---

And thats is the Problem. Why not add an flag to the packets that this is allowed to install this an an user. If the packet manager is called as an non root user. he install it in your home directory or maybe an separate folder ( maybe /opt/$user )