[RFC] consensus on $distfiles

[fosslinux]

There are varying opinions among maintainers in regards to how best to structure $distfiles.

For some time there has been an xlint rule that there must not be any variables in $homepage, which is good to me. However, when the distfile is contained underneath the homepage, such as for most github projects, there are two conflicting opinions among Void maintainers, namely whether or not to contract/expand $homepage in the template. For example, distfiles=https://github.com/emersion/xdg-desktop-portal-wlr/archive/v${version}.tar.gz v.s. distfiles=${homepage}/archive/v$version.tar.gz.

For a new contributor, this is often very confusing, when one maintainer reviews and asks to shorten/expand and then another maintainer responds with asking not to do this. I have seen this happen many times before, one example being #23296 (comment).

To rectify this issue:

1. Add a note to Manual.md on a consensus on what should be done.
2. Create an xlint rule.

(feel free to edit below)

Pros for contracting (i.e. using ${homepage}):

1. Shorter variable declarations
2. Less places to change if upstream moves github, for example.

Pros for expanding (i.e. not using ${homepage}):

1. Easier to copy-paste urls
2. "obfuscates" url

@void-linux/pkg-committers (if i can even do that)

[Piraty]

@void-linux/pkg-committers

[ahesford]

+1 for encouraging use of variables whenever possible in distfiles.

The primary justification for keeping the homepage and change log free from variables is that these things should be easy to copy and paste (or, in some terminal emulators, directly clickable).

No such justification applies to distfiles, which are already encouraged to use $version. It would be inconsistent and, in my view, senseless to demand that some variables be used while others be avoided.

When I make changes, I use the shortest possible form for distfiles. However, I tend not to demand a specific style when reviewing others' work. (Although I may suggest such a change when it would be one of many other demands.)

EDIT: sorry for the accidental close.

[Duncaen]

Less places to change if upstream moves github, for example.

More places to change if upstream gets a real homepage.

IMHO the less variables used in templates the better, it makes things easier to parse and tools like xlint can't deal with variables.
There is no real upside, if the homepage and distfiles URL is changed then you can simply change both lines.

[Anachron]

I'm not a committer but I would agree to always expand URL variables when possible. User scripts (like xtools) will have it a lot easier handling package templates.

[sgn]

FWIW, I don't like to use ${homepage} in ${distfiles}

[ericonr]

I like using ${homepage}, but it's also because it's expected (by me, at least) that most projects won't move off of GitHub/Gitlab. Makes for a shorter link, which is less visual noise.

I would ask that ${pkgname} be removed from distfiles, though, since we have many that are like https://github.com/user/${pkgname}/archive, which is the worst of both options. If the link gets too big by expanding pkgname, IMO it's better to at least use homepage directly.

[Vaelatern]

I don't like to use ${homepage} or ${pkgname} because the full-tree update checking script doesn't replace them.

Edit: That's in the homepage var itself, not distifles. For distfiles, I typically just replace the version these days.

e.g. it IS possible for python packages to have a single URL for all python packages with nothing hardcoded, but this makes it difficult to read.

[Piraty]

ever grep -r 'distfile=.*someurl.org' srcpkgs'ed ? no $homepage in $distfiles please.

[Chocimier]

I prefer to avoid variables, for simplicity of processing as text.

"Less places to change if upstream moves github" is case only for changed account on same hosting. If hosting is changed, distfiles need to be changed anyway.

[ericonr]

For what it's worth, we also use a bunch of GNOME_SITE, PYPI_SITE, etc, across distfiles. In my opinion, those are kinda worse, since the link can't even be found in the template itself, and I have to open another file to find it. If we decide to make ${homepage} "forbidden", we should remove those variables as well.

[Vaelatern]

Those variables have a well established purpose of making sure we hit the correct centralized distribution server, and are able to change mirrors in a reasonable way. Even if we have not used that capability, I find this valuable.

[subnut]

I propose to pin this issue to increase visibility

[ahesford]

There is no consensus; pinning the issue and attracting new attention to an unresolved debate that has no functional consequence doesn't offer any benefit.

[github-actions]

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.