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

[Ludovic Courtès]

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?

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

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.

Thanks for the neat hack!

Ludo’.