(computed-origin-method) and (origin)'s file-name field

(computed-origin-method) and (origin)'s file-name field

[Adam Faiz]

Hello everyone,

I'm wondering about the solution to the computed-origin-method workaround...
Must the 'computed-origin-method' workaround be solved by adding the renaming capability to snippets?

Why couldn't the file-name field of the source origin be used to rename it?

If it's because the upstream source might be confused with the liberated version, couldn't a comment above the snippet clarify that?

Re: (computed-origin-method) and (origin)'s file-name field

[Simon Tournier]

Hi,

On Sun, 27 Aug 2023 at 20:25, Adam Faiz <adam.faiz@disroot.org> wrote:

> Must the 'computed-origin-method' workaround be solved by adding the
> renaming capability to snippets?
>
> Why couldn't the file-name field of the source origin be used to
> rename it?
>
> If it's because the upstream source might be confused with the
> liberated version, couldn't a comment above the snippet clarify that?

To my knowledge, computed-origin-method predates current snippet
features and I think no one has taken the time to see if the same could
be achieved.

Well, this computed-origin-method workaround is used 5 times:

--8<---------------cut here---------------start------------->8---
5 candidates:
./gnu/packages/gnuzilla.scm:569:      (method computed-origin-method)
./gnu/packages/gnuzilla.scm:1198:      (method computed-origin-method)
./gnu/packages/linux.scm:375:       (method computed-origin-method)
./gnu/packages/emacs-xyz.scm:8788:         (method (@@ (guix packages) computed-origin-method))
./gnu/packages/emacs-xyz.scm:29603:       (method (@@ (guix packages) computed-origin-method))
--8<---------------cut here---------------end--------------->8---

I bet that ’snippet’ could be used for the two Emacs package cases.
Another story. :-)

That’s said, ’computed-origin-method’ delays what ’snippet’ does not,
IIRC.

For references, Mark’s – who introduced computed-origin-method back on
2019 – message is [1].  Mark’s comment [2] makes clear that this
workaround needs to be somehow revisited,

        I've always viewed 'computed-origin-method' as a temporary hack
        to work around limitations in the 'snippet' mechanism.  Most
        importantly, last I checked, it was not possible for a 'snippet'
        to produce a tarball with a different base name than the
        original downloaded source.  I consider it a *requirement* for
        the 'icecat' source tarball and it's unpacked directory to be
        named "icecat-…" and not "firefox-…", and similarly for
        'linux-libre'.

and the lengthy thread in patch#50620 [3] contains some discussions for
improving the situation.  Because the number of packages requiring
computed-origin-method is very low, there is few progress.  One good
start would to collect and extract all the ideas from #50620.


Cheers,
simon


1: Re: ‘computed-origin-method’ for IceCat and ungoogled-chromium
Fri, 30 Aug 2019 18:41:49 -0400
id:87woeuwa0n.fsf@netris.org
https://yhetil.org/guix/87woeuwa0n.fsf@netris.org
https://lists.gnu.org/archive/html/guix-devel/2019-08

2: https://issues.guix.gnu.org/50515#3-lineno61
3: https://issues.guix.gnu.org/50620#12