Le dimanche 14 octobre 2018 à 18:56 +0200, Fabio Valentini a écrit : > > You know that GitHub has supported the same thing for a long time? > The URL " > https://github.com/project/repo/archive/$REF/whatever-I-feel-like-1.0.tar.gz > " > will produce an archive of ref $REF (be it a tag, commit, or branch) > with the file name "whatever-I-feel-like-1.0.tar.gz". The forge macros > just don't make use of that feature, Actually, they do, that's the exact change you're complaining about here. And whatever-I-feel-like-1.0.tar.gz is useless because the topdir inside whatever-I-feel-like-1.0.tar.gz is definitively not whatever-I-feel- like-1.0, so you need to compute the actual topdir GitHub will generate and while you're at it the filename better match it or much %setup hilarity and packager unhappiness will ensue. And besides the code handle other things that GiHub that have changed behaviour over time. > but use the old "#anchor hack", > which not even the SourceURL packaging guidelines mention anymore. When the code was written it matched the guidelines whenever they produced working URLs (some guidelines didn’t). The guidelines and the code have been improved and fixed since. One reason the guidelines have been fixed is that the forge macro showed they were erroneous. > You know that github supports the same thing already, right? (Except > the "v" that's inserted before tags that don't match SemVer.) Ha ha ha. “except” v. And v does not have any simple rule, it is GiHub heuristic pile land, you have projects with some of their releases that uses v and others not, and GitHub can not even make up its mind in how to use it consistently for the same project release (it's in the url but not in the archive). I so wish GitHub would just give up on the whole v thing. Or do it all the time. But not sometimes yes, other times no. Since Google uses v in googlecode, and other hosting services do not, and GitHub tries to mirror everyone, their setup is doomed to fail as long as they do not standardise release tags git-upstream-side. By they still try to heuristic the problem away. > > — lobby git upstream to create a first-class release tag, with the > > same > > syntax for every hosting service and project, so I can kill the huge > > pile of heuristics that tries to guess what a specific project will > > use. > > An heuristic as everyone knows is something that works perfectly > > most of > > the time and fails miserably the rest of the time. And it is > > definitely > > *not* stable over time. > > Sure, upstream projects can always do stupid things ... but I don't > think that "stupid" should be the base-line here. > > > Alternatively, you can hardcode an url and archive name in your spec > > files, the result will be stable within the spec, but probably not > > work > > anymore whenever you need to bump the project version or commit. > > I've been doing exactly that for all my ~50 github based projects for > two years now, following this scheme: > > for stable releases: > - URL: https://github.com/project/%{name} > - Source0: %{url}/archive/%{version}/%{name}-%{version}.tar.gz > - %{autosetup} > > for snapshots (setting commit myself and computing shortcommit > automatically): > - URL: https://github.com/project/%{name} > - Source0: %{url}/archive/%{commit}/%{name}-%{shortcommit}.tar.gz > - %autosetup -n %{name}-%{commit} > > And this never broke. Not once. > > Which is why the SourceURL packaging guidelines recommend using > exactly these schemes. > (They already do so for github for a long time, and I updated them > some time ago for the new and better URLs that gitlab supports now.) > > But I've been trying to tell you this when the original forge macros > were introduced, and that has led nowhere either. > > So, I'll probably just gradually move back to using the Source URLs > for github/gitlab which are _actually documented_ in the Guidelines > and produce _stable_ results. > > Fabio > > > Regards, > > > > -- > > Nicolas Mailhot > > _______________________________________________ > > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx -- Nicolas Mailhot _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
