Hi, On Mon, 16 Nov 2020 at 13:03, Pierre Neidhardt <m...@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
