GNU bug report logs - #73034
[PATCH] gnu: git: Fix perl search-paths of wrapped programs.

Previous Next

Full log

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

From: Simon Tournier <zimon.toutoune <at> gmail.com>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: ludo <at> gnu.org, 73034 <at> debbugs.gnu.org, liliana.prikler <at> gmail.com
Subject: Re: [bug#73034] [PATCH v3 0/3] Fix annoyances of Git and update to
 2.46.0
Date: Fri, 06 Sep 2024 12:31:21 +0200

Hi Maxim,

On Fri, 06 Sep 2024 at 13:17, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> wrote:

>> And this appears to me a bad idea, because 1. it makes harder to know what are
>> the inputs and more importantly 2. it is hidden from procedure
>> ’package-direct-sources’, which means it will not be archived.
>
> I believe your argument 1. is going to affect any label-free package
> definitions needing additional origins copied in, so the issue is bigger
> than just this commit, in my opinion.

Well, is it not changing the scope of the work being reviewed?

If not, sorry, I do not understand what you mean.  Could you explain more?

In my views, what comes from the outside should be listed under inputs,
native-inputs or propagated-inputs.  I mean, that’s somehow the
principle from functional paradigm.  Putting an ’origin’ inside an
arguments is somehow a way to get around that principle, IMHO.

For instance, packages farstream, gnulib-checkout, smithforth,
gnome-recipes and dmd-bootstrap should also be fixed.

If you mean that it’s not easy to fix, from my understanding, it changes
the scope of the work being reviewed but let take the opportunity to
discuss. :-)

Currently it’s not possible to write something like:

--8<---------------cut here---------------start------------->8---
(native-inputs (append
                    (list
                     `("foo"
                       ,(origin
                          (method git-fetch)
                          (uri (git-reference
                                (url "https://somewhere.org/plop")
                                (commit (string-append "v" version))))
                          (file-name (git-file-name "plip" version))
                          (sha256
                           (base32
                            "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx")))))
                    (list bar baz and other)))
--8<---------------cut here---------------end--------------->8---

It appears to me that something is lacking: inputs-append. ;-)  We could
have a macro or a procedure that does the dance, allowing to mix both
“styles”.


> About 2; perhaps it'd be preferable to build the doc from source, if
> that doesn't introduce cycles or too large of a native inputs graph.

This is out of the scope, IMHO.  Yes, I agree: it might be preferable
but while waiting, it appears to me even more preferable to not have a
package that hides all its sources. ;-)

Cheers,
simon

Previous Next

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