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. 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). 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. 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). 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. 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 — 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. 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. 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
