On Sun, Oct 14, 2018 at 6:14 PM Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> 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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproject.org