[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#49149] [PATCH 0/7] Add deb format for guix pack.
From: |
Ludovic Courtès |
Subject: |
[bug#49149] [PATCH 0/7] Add deb format for guix pack. |
Date: |
Thu, 01 Jul 2021 15:20:46 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Hello,
Maxim Cournoyer <maxim.cournoyer@gmail.com> 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