[bug#73034] [PATCH v3 0/3] Fix annoyances of Git and update to 2.46.0

[Simon Tournier <zimon.toutoune@gmail.com>]

Hi Maxim,

On Fri, 06 Sep 2024 at 13:17, Maxim Cournoyer <maxim.cournoyer@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