On Sun, Oct 14, 2018 at 6:14 PM Nicolas Mailhot <nicolas.mailhot@xxxxxxxxxxx> wrote: > > Le dimanche 14 octobre 2018 à 15:37 +0200, Fabio Valentini a écrit : > > > > It looks like the forge macros weren't tested to be backwards > > compatible, because packages that build successfully now fail to build > > on rawhide (see, for example, build [0]). > > Fabio, > > You can’t assume the archive name returned by forge macros will be > stable over time. Why not? I would surely hope that the file names are stable. Otherwise packages might just randomly break in rawhide. Oh, wait ... > First, because GitHub, GitLab, etc are not themselves stable over time. > They change their URLs and the files those URL generate regularly. > Sometimes they change due to issues filled by Fedora people (as happened > to GitLab recently after Neal Gompa pointed problems in their old URLs). 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, but use the old "#anchor hack", which not even the SourceURL packaging guidelines mention anymore. > Second, because at any time they allow access to the same files through > multiple URLs, and the one Fedora chooses to use may change over time, > due to better understanding of the (undocumented) way forge work, or the > old URL not working for some projects, and so on. > > The forge macros abstract all this complexity away, so you do not need > to read the wiki and rewrite your spec file every time Fedora a hosting > service changes its rules or Fedora changes its preferred URL pattern. > The drawback being, the resulting archive filename *may* change from the > one in the lookaside cache over time. You can not both adapt > transparently to changes, and not-change filenames impacted by those > changes. Of course you can - if you map "unstable URLs" to the expected file names. I thought that's what the "abstraction" is for. > In the specific case you hit the old code required that you set a tag > and the new code will work even without a vversion tag, and recognizes > that the tag you set is really a version tag. So, net win for everyone > except packagers that had to workaround via a tag the fact the older > code was not smart enough. > > The macro still computes for your spec a correct archive URL and a > correct archive name. Archive name which BTW is better than the previous > one since it removes the v GitHub loves to inject in random places, and > matches the archive name one would get today in clicking on GitHub’s > download link (no idea if the old URL you used before still works and > even if it did how long GitHub will keep it working now it switched to > newer better API for its own service). The URL used for the download is _exactly_ the same as before this change, just the "#repo-vVersion.tar.gz" anchor is different now than it was before - so that's entirely in macros.forge's hands and has nothing to do with GitHub. > Also, the next version of the forge macro with is being proposed in > https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/35 > > will give you more flexibility and isolate archive-specific metadata > block so you can build a download for a tag unrelated to the package > version if that's what you want. > > So, the problem you hit is annoying but it's only a spectool away. And > we should probably sync older Fedora releases to the same level of forge > macros once the new redhat-rpm-config gets some use in devel. It might be easy, but do I want to waste time on this? No. > Now, if you want to avoid this kind of problem in the future: > > — lobby hosting services to commit to and document a stable set of APIs > to retrieve project archives (not just an URL set in stone, an URL that > produces the same filename with the same topdir inside). That's > basically what Neal did for Gitlab and why I have good hopes that GitLab > archive and url naming will be stable now You know that github supports the same thing already, right? (Except the "v" that's inserted before tags that don't match SemVer.) > — 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
