Re: A plan for parameterized packages

[zimoun]

Hi,

On Mon, 16 Nov 2020 at 13:03, Pierre Neidhardt <mail@ambrevar.xyz> wrote:

> See point 7. about conflicts:
>
> https://lists.gnu.org/archive/html/guix-devel/2020-01/msg00026.html

Quoting for instance the 2 examples:

        For instance, use guile-2.2.4 instead of guile for all guile
        libraries, or use pulseaudio everywhere, including in
        dependencies that are not explicitly installed to the user
        profile.

>From my understanding, the first case (guile) is now covered by the
“package rewriting” transformation (see package-input-rewriting IIUC).

The issue with the second case is below.


> and comments:
>
> https://lists.gnu.org/archive/html/guix-devel/2020-01/msg00177.html

>From my understanding of the Ludo’s patch and from the Marius’s message,
the both looks really similar. :-)


> https://lists.gnu.org/archive/html/guix-devel/2020-01/msg00181.html

Quoting:

        To be usable, we would need something to say "build bar and all
        its inputs without pulseaudio, except for some given packages".

        While this is OK with 1 parameter, it's quickly gets much more
        complicated when packages have multiple parameters that maybe conflict
        with one another.

Is the combinatorial conflict solvable in advance?  Well, from my point
of view, it cannot be via package transformation.

For example, let’s consider the Emacs packages and #41732.  Quoting [1]:

        > Perhaps then,
        >
        > --8<---------------cut here---------------start------------->8---
        > guix build -m manifest.scm --with-input=emacs-minimal=emacs-next \
        >      --with-input=emacs=emacs-next
        > --8<---------------cut here---------------end--------------->8---

        Possibly. And then Magit uses emacs-no-x as an input, so we may
        need to also add --with-input=emacs-no-x=emacs-next to the
        command.

        I'm just pointing out that the process is not as straightforward
        as it might seem. So, it doesn't sound right to simply suggest

and [2]:

        For example, the package emacs-magit drags emacs-no-x because of
        emacs-libgit, why is emacs-minimal not enough here?

        Well, the emacs-build-system depends (implicitly) on emacs-minimal,
        only.  And the initial patch `package-with-emacs-next' was changing
        this, only.  However, the package emacs-libgit is cmake-build-system
        and the package emacs-no-x is an explicit dependency; which is another
        story. :-)

these both examples show that it is already complex enough just to
rebuild all the Emacs packages using another Emacs VM (emacs-next or
REmacs, etc.).

To be clear, I am not convinced that the current package recipes are
functional enough to be able to keep under control the combinatorial
conflict; in the general case.

1: <http://issues.guix.gnu.org/issue/41732#14>
2: <http://issues.guix.gnu.org/issue/41732>

All the best,
simon