guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#71371] [PATCH v2] gnu: svn-fetch: Allow specifying revisions as str


From: Maxim Cournoyer
Subject: [bug#71371] [PATCH v2] gnu: svn-fetch: Allow specifying revisions as strings.
Date: Tue, 18 Jun 2024 14:26:14 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

Hi,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>>
>>> * guix/svn-download.scm (<svn-reference>):
>>> (svn-fetch):
>>> (svn-multi-fetch):
>>> * guix/build/svn.scm (svn-fetch): Revision can also be a string, not only
>>> a number.
>>> * doc/guix.texi (origin Reference): Document changes about REVISION field.
>>>
>>> Change-Id: Ibb17b539575fdf3daf895bd1ce39a40dd9b495cb
>>> ---
>>> v2: No longer ignore "-r" argument. Instead, allow strings, such as "HEAD". 
>>> Yes, in practice, it means this relies on the tag being stable, which is 
>>> the same assumption as for, e.g., tarballs. WDYT?
>>
>> While it may be useful to point to volatile references such as HEAD for
>> internal projects (like I believe is also possible for our git fetcher)
>> or the likes (with a hash of #f for example), I wouldn't like to see
>> this used in the Guix tree (I'd consider it a bad practice).  I'm not
>> against merging this, but I think we should add a 'guix lint' rule
>> that'd warn that some SVN reference should be specified if it wasn't.
>>
>> Does that sound reasonable?
>
> To be clear, I intend to use it in Guix tree, _in conjunction with
> a tag_. The purpose of this patch is to put the reference on the
> human-readable repository tag, not on the revision number.

[...]

> Again, as also pointed out, we trust tarballs, but the situation is
> exactly the same for them: one evil project could modify the contents of
> the tarball without changing its name. The consequence would then be the
> same: a hash mismatch.
>
> Anyway, this patch is there to make my life less miserable while writing
> a TeX Live updater. It is of no use (to me) if it is restricted to
> internal projects. I'm not putting pressure on anyone though, if it
> isn't accepted, I'll find other, probably more tedious, ways to complete
> the updater.

I see.  I don't have a strong opinion, if it eases the maintenance of
the many texlive packages we carry, but it seems to me that an updater
could do the work of associating an immutable SVN reference to a tag at
the time of the import.

-- 
Thanks,
Maxim





reply via email to

[Prev in Thread] Current Thread [Next in Thread]