| Message ID | 20210621061039.31557-1-maxim.cournoyer@gmail.com |
|---|---|
| Headers | show |
| Series | Add deb format for guix pack. | expand |
This is awesome! Are you working on adding a-packs support for alpine linux also?
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’.
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
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. >> 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? > 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. Thanks, Ludo’.
Hi, I am a bit late to the party. Thanks for this good idea of pack. Neat! On Wed, 30 Jun 2021 at 11:15, Ludovic Courtès <ludo@gnu.org> wrote: > 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. The simple scenario: scp \ $(guix pack -f deb hello -C xz -S /usr/bin/hello=bin/hello) \ remote:/tmp/ ssh remote sudo apt install /tmp/…-hello-deb-pack.deb realpath $(which hello) /gnu/store/…-hello-2.10/bin/hello works fine. Then, I am probably doing wrong: sudo apt remove hello hello -bash: hello: command not found guix help bash: /home/simon/.config/guix/current/bin/guix: /gnu/store/…-guile-wrapper/bin/guile: bad interpreter: No such file or directory I have not investigated. Just a quick test for this nice new feature. Cheers, simon
Hi, Using Guix ebf07a0. I do not know if the issue is about multi-debs or if I am doing something wrong but IIUC ’apt’ remove all the files under data/. $ /gnu/store/3v93dzrmh978mljw65zvvydm2w8lqaam-guile-wrapper/bin/guile --version guile (GNU Guile) 3.0.7 Copyright (C) 2021 Free Software Foundation, Inc. License LGPLv3+: GNU LGPL 3 or later <http://gnu.org/licenses/lgpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. $ guix gc --references /gnu/store/3v93dzrmh978mljw65zvvydm2w8lqaam-guile-wrapper /gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib /gnu/store/226ljnvrhnrb3ngjn0m6i5ih2301bbj0-guile-launcher.c /gnu/store/6l9rix46ydxyldf74dvpgr60rf5ily0c-guile-3.0.7 /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31 /gnu/store/xa45bzcbib4zqa7gk70nb35dzzwyr376-gcc-toolchain-7.5.0 $ sudo apt install y74azsczq1dws1slmagc1jq6ysidllpb-hello-deb-pack.deb $ guix gc --references $(realpath $(which hello)) /gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10 /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31 $ sudo apt remove hello $ ls /gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib ls: cannot access '/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib': No such file or directory $ ls -l /gnu/store/3v93dzrmh978mljw65zvvydm2w8lqaam-guile-wrapper/bin/guile -r-xr-xr-x 2 root root 17472 Jan 1 1970 /gnu/store/3v93dzrmh978mljw65zvvydm2w8lqaam-guile-wrapper/bin/guile $ /gnu/store/3v93dzrmh978mljw65zvvydm2w8lqaam-guile-wrapper/bin/guile --version bash: /gnu/store/3v93dzrmh978mljw65zvvydm2w8lqaam-guile-wrapper/bin/guile: No such file or directory $ ar -xv y74azsczq1dws1slmagc1jq6ysidllpb-hello-deb-pack.deb x - debian-binary x - control.tar.xz x - data.tar.xz $ tar Jtf data.tar.xz | grep glibc | head ./gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.5.0/plugin/include/config/glibc-stdint.h ./gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/ ./gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/bin/ ./gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/bin/catchsegv ./gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/bin/gencat ./gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/bin/getconf ./gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/bin/getent ./gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/bin/iconv ./gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/bin/ldd ./gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/bin/locale Therefore, installing and then removing ’hello’ breaks any other pack using, for instance, 01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib or fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31. Do I miss something? Cheers, simon
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
Hi Zimoun, zimoun <zimon.toutoune@gmail.com> writes: > Hi, > > I am a bit late to the party. > > Thanks for this good idea of pack. Neat! > > > On Wed, 30 Jun 2021 at 11:15, Ludovic Courtès <ludo@gnu.org> wrote: > >> 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? After thinking it out some more, yes! This is because the files are not part of another deb, so dpkg will just claim ownership of the files. >> Admittedly it makes little sense to do something like this, but that’s >> something one could do. Indeed. I'll a disclaimer in the manual. > The simple scenario: > > scp \ > $(guix pack -f deb hello -C xz -S /usr/bin/hello=bin/hello) \ > remote:/tmp/ > ssh remote > sudo apt install /tmp/…-hello-deb-pack.deb > realpath $(which hello) > /gnu/store/…-hello-2.10/bin/hello > > works fine. Then, I am probably doing wrong: > > sudo apt remove hello > hello > -bash: hello: command not found > > guix help > bash: /home/simon/.config/guix/current/bin/guix: /gnu/store/…-guile-wrapper/bin/guile: bad interpreter: No such file or directory So uninstalling the hello deb caused all the files "owned" by that debian package to be removed, breaking the guix installed on that same system. It's becoming obvious that the deb-packs are not to be used on systems where Guix is already installed nor mixed with other non-deb packs. That's unfortunate, but there doesn't seem to be much we can do other than document these shortcomings. > I have not investigated. Just a quick test for this nice new feature. Thanks for the feedback! Maxim
Hi Simon, [...] > Therefore, installing and then removing ’hello’ breaks any other pack > using, for instance, 01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib or > fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31. Do I miss something? No, your analysis is correct. I'm currently writing adding a disclaimer in the manual, will post it here. Thanks, Maxim
Hi again,
How about adding these notes/disclaimers to prevent users breaking their
Guix or existing packs on foreign distributions?
--8<---------------cut here---------------start------------->8---
doc: Add a note and warning regarding the usage of deb packs.
* doc/guix.texi (Invoking guix pack): Move to the end of the table, and add a
note and warning regarding the usage of deb packs.
1 file changed, 21 insertions(+), 5 deletions(-)
doc/guix.texi | 26 +++++++++++++++++++++-----
modified doc/guix.texi
@@ -6028,11 +6028,6 @@ This produces a SquashFS image containing all the specified binaries and
symlinks, as well as empty mount points for virtual file systems like
procfs.
-@item deb
-This produces a Debian archive (a package with the @samp{.deb} file
-extension) containing all the specified binaries and symbolic links,
-that can be installed on top of any dpkg-based GNU/Linux distribution.
-
@quotation Note
Singularity @emph{requires} you to provide @file{/bin/sh} in the image.
For that reason, @command{guix pack -f squashfs} always implies @code{-S
@@ -6047,6 +6042,27 @@ If you forget the @code{bash} (or similar) package, @command{singularity
run} and @command{singularity exec} will fail with an unhelpful ``no
such file or directory'' message.
@end quotation
+
+@item deb
+This produces a Debian archive (a package with the @samp{.deb} file
+extension) containing all the specified binaries and symbolic links,
+that can be installed on top of any dpkg-based GNU/Linux distribution.
+
+@quotation Note
+Because archives produced with @command{guix pack} contain a collection
+of store items and because each @command{dpkg} package must not have
+conflicting files, in practice that means you likely won't be able to
+install more one such archive on the same system.
+@end quotation
+
+@quotation Warning
+@command{dpkg} will assume ownership of any files contained in the pack
+that it does @emph{not} know about. It is unwise to install
+Guix-produced @samp{.deb} files on a system where @file{/gnu/store} is
+shared by other software, such as a Guix installation or other, non-deb
+packs.
+@end quotation
+
@end table
@cindex relocatable binaries
--8<---------------cut here---------------end--------------->8---
Thanks,
Maxim
Hi again, Maxim Cournoyer <maxim.cournoyer@gmail.com> writes: [...] > +@quotation Note > +Because archives produced with @command{guix pack} contain a collection > +of store items and because each @command{dpkg} package must not have > +conflicting files, in practice that means you likely won't be able to > +install more one such archive on the same system. > +@end quotation With typo fixed: -install more one such archive on the same system. +install more than one such archive on a given system. Maxim
Hi Maxim, On Wed, 30 Jun 2021 at 13:28, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote: > --8<---------------cut here---------------start------------->8--- > doc: Add a note and warning regarding the usage of deb packs. [...] > +@item deb > +This produces a Debian archive (a package with the @samp{.deb} file > +extension) containing all the specified binaries and symbolic links, > +that can be installed on top of any dpkg-based GNU/Linux distribution. > + > +@quotation Note > +Because archives produced with @command{guix pack} contain a collection > +of store items and because each @command{dpkg} package must not have > +conflicting files, in practice that means you likely won't be able to > +install more one such archive on the same system. > +@end quotation > + > +@quotation Warning > +@command{dpkg} will assume ownership of any files contained in the pack > +that it does @emph{not} know about. It is unwise to install > +Guix-produced @samp{.deb} files on a system where @file{/gnu/store} is > +shared by other software, such as a Guix installation or other, non-deb > +packs. > +@end quotation > + > @end table > > @cindex relocatable binaries > --8<---------------cut here---------------end--------------->8--- The pack does not fully respect the FHS from the Debian Policy, right? Hum, the disclaim LGTM. Although, it appears to me a severe limitation to be able to install only one Guix-generated .deb pack on a Debian-like system, IIUC. :-) Cheers, simon
Hi Simon, zimoun <zimon.toutoune@gmail.com> writes: > Hi Maxim, > > On Wed, 30 Jun 2021 at 13:28, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote: >> --8<---------------cut here---------------start------------->8--- >> doc: Add a note and warning regarding the usage of deb packs. > > [...] > >> +@item deb >> +This produces a Debian archive (a package with the @samp{.deb} file >> +extension) containing all the specified binaries and symbolic links, >> +that can be installed on top of any dpkg-based GNU/Linux distribution. >> + >> +@quotation Note >> +Because archives produced with @command{guix pack} contain a collection >> +of store items and because each @command{dpkg} package must not have >> +conflicting files, in practice that means you likely won't be able to >> +install more one such archive on the same system. >> +@end quotation >> + >> +@quotation Warning >> +@command{dpkg} will assume ownership of any files contained in the pack >> +that it does @emph{not} know about. It is unwise to install >> +Guix-produced @samp{.deb} files on a system where @file{/gnu/store} is >> +shared by other software, such as a Guix installation or other, non-deb >> +packs. >> +@end quotation >> + >> @end table >> >> @cindex relocatable binaries >> --8<---------------cut here---------------end--------------->8--- > > The pack does not fully respect the FHS from the Debian Policy, right? > > Hum, the disclaim LGTM. Although, it appears to me a severe limitation > to be able to install only one Guix-generated .deb pack on a Debian-like > system, IIUC. :-) Thanks! It is! One thing that would be possible is react to a user passing the -R(R) (relocatable) option and keep the deb pack contents under a named prefix, such as /opt/deb-packs/name/gnu/store/[...] to keep them from conflicting. I won't be pursuing it myself but it shouldn't be too difficult to do! Maxim
Hi Maxim, On Wed, 30 Jun 2021 at 21:20, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote: > > Hum, the disclaim LGTM. Although, it appears to me a severe limitation > > to be able to install only one Guix-generated .deb pack on a Debian-like > > system, IIUC. :-) > > Thanks! It is! One thing that would be possible is react to a user > passing the -R(R) (relocatable) option and keep the deb pack contents > under a named prefix, such as /opt/deb-packs/name/gnu/store/[...] to > keep them from conflicting. I won't be pursuing it myself but it > shouldn't be too difficult to do! I understand. I keep this idea / feature under the elbow (well, have this in reserve :-)). Cheers, simon
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
Hi, On Thu, 1 Jul 2021 at 15:21, Ludovic Courtès <ludo@gnu.org> wrote: > Work on layered Docker images, notably by Chris Baines¹, could perhaps > be handy here. Do you mean something à la Nixery [1]? 1: <https://tazj.in/blog/nixery-layers> > ¹ https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00299.html Cheers, simon
zimoun <zimon.toutoune@gmail.com> skribis: > On Thu, 1 Jul 2021 at 15:21, Ludovic Courtès <ludo@gnu.org> wrote: > >> Work on layered Docker images, notably by Chris Baines¹, could perhaps >> be handy here. > > Do you mean something à la Nixery [1]? > > 1: <https://tazj.in/blog/nixery-layers> Yes. Ludo'.