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

[Maxim Cournoyer]

Hello!  Seems this one had fallen into the cracks of my hundred
something long mailbox.  Sorry!

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

> Hello!
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> This patch set adds support to produce Debian archives (.deb packages) via
>> guix pack.  It's rudimentary but functional.  You can try a simple example
>> like so:
>>
>> $ ./pre-inst-env guix pack -f deb -C xz hello -S /usr/bin/hello=bin/hello
>>
>> Copy the generated .deb to your dpkg-based distribution of choice, then:
>>
>> $ sudo apt install ./91ypmi1j5py9qk034kki5wrgy0n52yz9-hello-deb-pack.deb
>>
>> $ realpath $(which hello)
>> /gnu/store/lk9cmjjhgxpkxxi7m54y0jlv3rqvpb2n-hello-2.10/bin/hello
>> $ hello
>> Hello, world!
>>
>> Fun, no?  We can now distribute software built with Guix transparently to any
>> Debian-based distribution.
>
> Definitely fun.  :-)
>
> As briefly discussed on IRC, I wonder what happens when installing
> multiple such .deb files, and removing them selectively.  There’s of
> course going to be overlapping store items.

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

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

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.

> WDYT?  Is our official Debian ambassador around?  :-)
>
> A complementary approach would be to transparently build Guix packages
> in a Debian VM, with an FHS layout, and with dependencies on Debian
> packages.  I remember there were tools for that in Nixpkgs back in the
> day, using Checkinstall to generate the actual .deb file.

It could be fun!  Although my next 'guix pack' hack will have to be
--format=rpm, to complement this one ;-).

Thanks!

Maxim