Hello, Maxim Cournoyer skribis: >> Will that overwrite things in /gnu/store? >> >> Admittedly it makes little sense to do something like this, but that’s >> something one could do. > > It probably would conflict with what is already in the store (installed > by guix) and abort installation, guarding against this. OK. >>> Given you can't install two conflicting packages, the issue of removing >>> the files of another package cannot arise. In practice that means that >>> the current implementation of 'guix pack -f deb' would only allow >>> installing *one* such .deb package on a system at a time (most >>> applications will carry the glibc and thus conflict for example). >> >> I see. So the main value over “sudo tar xf” is that dpkg knows which >> files were installed, right? > > That's one good advantage (the ease of cleanly uninstalling the .deb), > but for me the main one is the ability to plug it in already established > distribution channels (such as a 3rd party apt repository) and have it > available (and updatable) easily for their users. Right. Though setting up an apt repo is quite a lot of work. Also, would upgrading the Guix-generated package work? I suppose apt would wipe /gnu/store of the former package and then unpack the new package, right? > A real world use case I've been playing with is to have the jami-qt > package that is painstakingly built for each flavor of the leading > Deb-based distributions and available for example in various > repositories [0] built once via 'guix pack -f deb' and made available in > the same way. That'd remove the need to wrestle with OS-specifics, and > make the build (and hopefully the bugs) reproducible while preserving > the established and reliable distribution channel. Nice! That’s an interesting use case. > I hope this is way of doing things is obsoleted one day when Guix can be > hooked in the GNOME software "store" the same as snaps or flatpaks can, > so that users don't need to know how the command line to benefit from > the advantages provided by Guix. True, having Guix as one of the app bundle options for GNOME Software would be nice. >>> For a multi deb-pack scenario, we could have each .deb install their own >>> files under for example /opt/guix/deb-packs/$name/gnu/store... via the >>> relocatable option. >> >> Hmm yeah, though it doesn’t sound pretty. > > In general, I find that 'guix pack's take a step away from elegance in > exchange for convenience, so that doesn't sound too terrible in that > context (it'd actually be easier to manage than a multi-tarball guix > packs deployment, for example, especially when comes the time to reclaim > some disk space). Yes, I agree that we need to be pragmatic here. :-) Work on layered Docker images, notably by Chris Baines¹, could perhaps be handy here. Or, actually, one option would be for ‘guix pack -f deb’ to generate one .deb file per store item. Does that sound reasonable?… Thanks, Ludo’. ¹ https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00299.html