GNU bug report logs - #49149
[PATCH 0/7] Add deb format for guix pack.

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 49149 <at> debbugs.gnu.org
Subject: [bug#49149] [PATCH 0/7] Add deb format for guix pack.
Date: Thu, 01 Jul 2021 15:20:46 +0200

Hello,

Maxim Cournoyer <maxim.cournoyer <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.