4 ms·
> a bit like mixing pkg and ports in BSD There is no mixing ports and pkgs in FreeBSD (I assume you mean that one). When you build a port, it builds a package
by 0x457 3y ago
> a bit like mixing pkg and ports in BSD
There is no mixing ports and pkgs in FreeBSD (I assume you mean that one). When you build a port, it builds a package and installs that. You run into big rebuilds/reinstalls when versions mismatch between your ports tree and pkgs repo.
Guix/nix can't be mixed with existing package managers, but can exist on the same machine. You're (most likely) going to have duplicates and different versions of the same thing.
- nonrandomstring 3y agoYes my previous is mainly with FreeBSD. Your response highlights my mistake. As a Guix noob (but with decades of apt/yum/rpm/pkg kinda experience) I misunderstood how these things interact, and failing to manage Guix was most definitely my fault. Don't get me wrong, I love Guix and the philosophy, but my heart cries out for some Grand Unified Manager of Packages (GUMP), something that can track whether things need building from source, or can be brought in as binary from an apt or rpm, or build those packages as intermediate stages. I kinda thought that's what Guix was going to do. Now I see that a unified package manager is probably unreasonable and that we are headed more toward containerised "Snap/flatpck" way of things - which I don't like.
- Arelius 3y ago> something that can track whether things need building from source, or can be brought in as binary from an apt or rpm, or build those packages as intermediate stages. I kinda thought that's what Guix was going to do. I mean, that sortof what nix (and I assume guix) is though, right? As long as your ok with the binary cache for a replacement for apt/rpm (with the caveat that sometimes pkgs can be built on .deb or .rpm)