Page 3 of 3 FirstFirst 123
Results 21 to 28 of 28

Thread: Guix: A New Package Manager & GNU Distribution

  1. #21
    Join Date
    Apr 2010
    Posts
    770

    Default

    Quote Originally Posted by timofonic View Post
    But distribution developers are full of massively developed egos, fanaticism and hidden commercial interests.
    Although not half as much as distro *fans*....

  2. #22
    Join Date
    Jun 2011
    Location
    Czech Republic
    Posts
    7

    Default Not really a mistake

    Quote Originally Posted by renox View Post
    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-*

  3. #23
    Join Date
    Jan 2012
    Posts
    19

    Default

    Quote Originally Posted by timofonic View Post
    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.

  4. #24
    Join Date
    Jun 2011
    Location
    Czech Republic
    Posts
    7

    Default Meta-standard

    Quote Originally Posted by mateli View Post
    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).

  5. #25
    Join Date
    Mar 2012
    Posts
    83

    Default It goes against the Unix principles

    Quote Originally Posted by vcunat View Post
    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.

  6. #26
    Join Date
    Sep 2010
    Posts
    229

    Default

    Quote Originally Posted by Nille View Post
    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...

  7. #27
    Join Date
    Sep 2010
    Posts
    229

    Default

    Quote Originally Posted by renox View Post
    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?

  8. #28
    Join Date
    Jul 2008
    Location
    Germany
    Posts
    686

    Default

    Quote Originally Posted by JanC View Post
    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 )

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •