GNU bug report logs - #41602
texlive is actually substitutable

Previous Next

Full log

Message #33 received at 41602 <at> debbugs.gnu.org (full text, mbox):

From: Morgan Arnold <morgan.arnold <at> proton.me>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 41602 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>,
 Leo Famulari <leo <at> famulari.name>
Subject: Re: bug#41602: texlive is actually substitutable
Date: Mon, 24 Feb 2025 15:17:39 +0000

Hi Maxim, Ludo,

I did a bit of work on this, and I think that there might be a problem with limiting the distribution of derivation outputs. The problem is with encoding that a derivation's outputs are non-distributable. Because `#:distributable?` should presumably be an argument to `derivation`, and because `guix publish` does not have access to the underlying derivation object, it seems necessary to store distributability information somehow, like is done with "allowSubstitutes" currently. The problem, then, is that when `guix publish` manages a request, what it has to work with is the path of the output being requested *not the derivation from which it was built*. I could be wrong, but I assume that there is no way to compute, from an output path, the path of the derivation which produced it.

It then seems impossible to effectively prevent distribution! I don't see a sane way to attach metadata to every single object in the store (all of which may, to the best of my understanding, be published), and even if we include information about distributability in the derivation file, there is no way for `guix publish` to locate that derivation file, since it is supplied with the path of the derivation output, not the derivation which produced it.

I would appreciate thoughts on this, but I am not sure if I see how `#:distributable?` is a workable solution. I agree that enforcing non-distribution on the client side is inelegant, but I don't see a way to enforce it server-side.

Best,

Morgan

Previous Next

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