On Sun, Oct 14, 2018 at 7:21 PM Nicolas Mailhot <nicolas.mailhot@xxxxxxxxxxx> wrote: > > 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. Ok. Let me backtrack. Since I don't assume that you broke a pile of packages on purpose, let's focus on how to fix this. Because right now, package builds prepared on fedora 27-29 will result in failing koji builds for rawhide - and nobody should have to install rawhide to be able to build packages. Fabio > > > — 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 _______________________________________________ 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
