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

[Maxim Cournoyer]

Hello!

Ludovic Courtès <ludo@gnu.org> writes:

> Howdy!
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>
> [...]
>
>>> Apparently, dpkg will happily overwrite them when you install (and
>>> that’s fine, if they have the same name, they’re identical), but what
>>> happens when you remove one of them?  Does it, for instance, remove
>>> /gnu/store/…-glibc just because it “belongs” to that package, without
>>> noticing that it also belongs to other installed packages?
>>
>> Actually, dpkg will error with a conflict message if two distinct
>> packages try to install the same file.  Only a package with the same
>> name can overwrite itself.
>
> Ah OK.
>
> Also, what happens if you do:
>
>   sudo apt install guix
>   guix install stuff …
>   sudo apt install ./guix-pack-generated.deb
>
> ?
>
> 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.

>>> If dpkg cannot deal with that, it’s equivalent to a tarball pack for all
>>> practical purposes, except you’d run “sudo apt” instead of “sudo tar”.
>>
>> 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.

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.

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.

[0]  https://dl.jami.net/nightly/debian_10/pool/main/j/jami/

>> 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).

My 2 cents :-).

Maxim