From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: Re: Parameterized packages Date: Fri, 10 Jan 2020 17:19:07 +0100 Message-ID: <87h813wah0.fsf@gnu.org> References: <87woitz1xx.fsf@gnu.org> <87o945vze5.fsf@nckx> <8736ldq74z.fsf@netris.org> <20190719202906.lbanx5puk7t6q4cr@cf0> <87a7753boq.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:52757) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ipx0D-0004uT-Vk for guix-devel@gnu.org; Fri, 10 Jan 2020 11:19:15 -0500 In-Reply-To: <87a7753boq.fsf@ambrevar.xyz> (Pierre Neidhardt's message of "Thu, 02 Jan 2020 20:23:01 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org Sender: "Guix-devel" To: Pierre Neidhardt Cc: guix-devel@gnu.org Hello! The way I see it, we=E2=80=99re still toying with the idea and its pros and cons=E2=80=94discussions about CLI syntax can come later. ;-) The added flexibility of package parameters is definitely nice, but really, maintainability is a big concern. The example Tobias gave (a parameter to enable/disable X11 support) is interesting because it shows that parameters can quickly become ubiquitous and get =E2=80=9Cout of contr= ol=E2=80=9D, from a maintenance viewpoint. Pierre Neidhardt skribis: > 7. Dependency management. > Also known as the USE flag nightmare among Gentoo users... > This is where hell breaks loose! :p > > The problem: the user wants to specify a parameter to use globally whe= re it > applies, on all installed packages and all their inputs, recursively. > > For instance, use guile-2.2.4 instead of guile for all guile libraries= , or > use pulseaudio everywhere, including in dependencies that are not expl= icitly > installed to the user profile. > > The obstacle: A package may require inputs with a specific parameter. > For instance, BAR depends on a FOO package built with ":audio > pulseaudio". What happens if the user seta ":audio alsa" globally > and installs BAR? BAR needs to specify explicitly that its FOO input > requires pulseaudio. Otherwise BAR would fail to build. > > To specify that a package input depends on a specific parameter, we co= uld > extend the syntax of the (inputs ...) and (native-inputs ...) fields l= ike so: > > (input > `(("foo" ,foo "(:audio pulseaudio)"))) > > A bigger problem is that the parameter compatibility issue is combinat= orial: > "Which parameter combination does BAR support?" It's hard to know it = in > advance. Any idea how to tackle this? That=E2=80=99s another good example of a problem that would arise. :-/ It doesn=E2=80=99t seem reasonable to me to add complex logic in (guix pack= ages) to deal with this issue; I would very much prefer to leave input handling unchanged. I=E2=80=99m worried about the maintenance cost of parameters. Having the feature is one thing, but being able to guarantee that the package combinations we offer all work is another one. We could have the feature and use it very seldom in Guix itself, but I=E2= =80=99m guessing that that=E2=80=99s not what you have in mind. Also, for CI purposes, we would need a way to enumerate all the possible combinations=E2=80=A6 Apologies for spoiling the party :-), but I think these concerns need all our attention! Thanks, Ludo=E2=80=99.