#2949 PR `merged`: Uptodate Source pointing to GitHub in RPM spec¶

Labels: bug, cleanup, fixed / solved / done

pcahyna opened issue at 2023-02-28 17:47:¶

Pull Request Details:¶

Type: Bug Fix
Impact: Low
Reference to related issue (URL): closes #2945
How was this pull request tested?
spectool -g packaging/rpm/rear.spec downloads the correct tarball
Brief description of the changes in this pull request:
Change the URL in the Source tag in the RPM spec file to point to the tarball on GitHub instead of SourceForge (where the tarball is not updated anymore).
AFAIK GitHub creates the tarballs automatically from tags.

pcahyna commented at 2023-02-28 18:06:¶

ToDo: the Makefile also needs updating, otherwise it will rewrite the spec when executingmake dist.

pcahyna commented at 2023-03-01 11:53:¶

I think you can simply remove the corresponding sed line from the Makefile and I would appreciate for you to do that as well within this PR.

About Gentoo: According to https://devmanual.gentoo.org/ebuild-writing/variables/index.html#renaming-sources I'd expect the URL line to look like this:
SRC_URI="https://github.com/rear/rear/archive/${PV}.tar.gz -> ${P}.tar.gz"
But indeed, a test by somebody using Gentoo would be nice, although I'd rather make this change blindly as not to change it - the old URL is 100% broken, the new one might just work.

ok, will do

schlomo commented at 2023-03-02 13:17:¶

Yes, agree with you that a more explicitly named tag would be useful.

pcahyna commented at 2023-03-02 13:28:¶

I think you can simply remove the corresponding sed line from the Makefile and I would appreciate for you to do that as well within this PR.

This won't work properly, because make dist constructs a tarball named e.g. rear-2.7-git.4965.531d9074.githubsourceinspecfile.changed.tar.gz under dist, so the Source: line needs to be updated to point to this tarball, otherwise rpmbuild invoked from make srpm would not find it (just tried that). But I can update the sed line to use a working URL (i.e. GitHub) for Source.

pcahyna commented at 2023-03-02 13:29:¶

ToDo: the Makefile also needs updating, otherwise it will rewrite the spec when executingmake dist.

it won't, because Makefile does not touch packaging/rpm/rear.spec, it constructs a temporary spec under dist (the message Rewriting packaging/rpm/rear.spec, packaging/debian/rear.dsc and usr/sbin/rear is misleading).

schlomo commented at 2023-03-02 13:32:¶

Good catch. I was also fighting our Makefile yesterday and would love to find a way how ReaR can run from source without modifying the source area at all.

For the Source: entry in the spec file, is any valid URL OK or must it actually match the content and the dist archive file name? I find it very important that the dist archive file name can continue to carry the full git branch and version info.

pcahyna commented at 2023-03-02 13:38:¶

For the Source: entry in the spec file, is any valid URL OK or must it actually match the content and the dist archive file name? I find it very important that the dist archive file name can continue to carry the full git branch and version info.

It does not need to be a URL at all. I would actually prefer the Makefile to keep only the file name in Source. URLs of type https://sourceforge.net/projects/rear/files/rear/2.7/rear-2.7-git.4965.531d9074.githubsourceinspecfile.changed.tar.gz, which the current Makefile produces, have never been correct even when SourceForge download was working and won't became more correct by changing them to github.com. I would prefer just Source: rear-2.7-git.4965.531d9074.githubsourceinspecfile.changed.tar.gz which expresses clearly that the tarball has been built locally and can't be found anywhere on the Internet.

pcahyna commented at 2023-03-02 13:41:¶

Good catch. I was also fighting our Makefile yesterday and would love to find a way how ReaR can run from source without modifying the source area at all.

have a look at the dist target - it produces modified sources under build without touching the original sources (except man).

pcahyna commented at 2023-03-02 13:44:¶

by the way, I believe ReaR can already run from source checkout without modifications - https://github.com/rear/rear#quick-start-guide

schlomo commented at 2023-03-02 13:50:¶

The problem is that ReaR running from source add os.conf and the log files
into the source tree. And uses it to build the rescue image.

And yes, running make shouldn't randomly recreate the manpages and docs
with a different asciidoc heading embedded.

pcahyna commented at 2023-03-02 13:52:¶

For the Source: entry in the spec file, is any valid URL OK or must it actually match the content and the dist archive file name?

if by dist archive file name you mean the archive file name that rpmbuild will actually use to build the source RPM, the last component of the Source URL must match it. This is because the last component of the URL is THE way to determine the source tarball name that rpmbuild uses. There is no independent way to provide it. OTOH, the URL does not need to be valid and indeed, as I wrote above, it does not need to be an URL at all, a local file name is enough.

pcahyna commented at 2023-03-02 13:55:¶

The problem is that ReaR running from source add os.conf and the log files into the source tree. And uses it to build the rescue image.

So the problem is that the rescue image will contain os.conf and log files? But IIRC this will be the case also for installed ReaR.

pcahyna commented at 2023-03-02 16:37:¶

@schlomo I think I addressed all the ToDos now.

pcahyna commented at 2023-03-03 09:27:¶

Looks good, not sure about the context where the full URL in the spec file will be used though.

For sure I see no harm so if it helps anybody then this is great.

The usual RPM build automation (rpmbuild and koji) do not use the full URL, only the last component (at least in Fedora, maybe the tooling for other distros is actually using it). The full URL is there mostly to document where the source can be obtained. Note that https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_troublesome_urls mentions cases where a URL can't be used, so only the file name is used in Source and the full URL is in a comment.

There is a tool though called spectool that automates the download of the source file : so instead of downloading the tarball manually, you can execute spectool -g packaging/rpm/rear.spec. For this, it is handy to have a correct URL. There may be other tooling that needs valid URL. (Packit builds executed from PRs do not need it though, because Packit rebuilds the tarball including the changes and changes Source to point to the tarball that it has built, in analogy with make dist.)

All in all, this PR is less important than it may seem. The incorrect URL was not causing any failure.

schlomo commented at 2023-03-03 10:03:¶

I'm also not super happy with out Makefile, but this PR is a good improvement and we learned something. Thanks a lot!

jsmeix commented at 2023-03-03 10:06:¶

In the openSUSE Build Service projects
Archiving:Backup:Rear and Archiving:Backup:Rear:Snapshot
I removed the build repository "SLE_11_SP4"
so ReaR gets no longer built there for SLE11, cf.
https://github.com/rear/rear/pull/2949#discussion_r1124225289
and old stuff for SLE11 in packaging/rpm/rear.spec
can be safely removed.

pcahyna commented at 2023-03-08 17:13:¶

@pcahyna I did the ReaR 2.7 release (my first release ever) according to https://github.com/rear/rear/wiki/Release-process as far as I could understand the instructions there and partially in some kind of "bona fide script kiddie" mode ;-) so feel free to enhance https://github.com/rear/rear/wiki/Release-process as needed.

@jsmeix thank you for showing us how this Makefile target is actually being used in the release process. If we decide to change the functionality of the target, we should definitely consider how it fits into the release process.

pcahyna commented at 2023-03-08 17:16:¶

@schlomo