git pseudo tags in spec files?
Hi, Some spec files contain commented pseudo tags like e.g #Git-Web: http://git.kernel.org/?p=utils/kernel/kmod/kmod.git;a=summary #Git-Clone: git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod The format is too widespread to be coincidence. Is this convention documented somewhere or just packagers adopting it randomly? Usually such a URL leads to the main upstream development branch. However for the context of the spec file it might be interesting to also specify the exact tag or commit the package is about. With that information one could simplify importing patches to git before rebase to a new version. So in case of kmod the spec file could have: #Git-Tag: v30 cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Ivo Totev HRB 36809 (AG Nürnberg)
On Thu, Sep 29, 2022 at 3:12 PM Ludwig Nussel <ludwig.nussel@suse.de> wrote:
Hi,
Some spec files contain commented pseudo tags like e.g
#Git-Web: http://git.kernel.org/?p=utils/kernel/kmod/kmod.git;a=summary #Git-Clone: git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod
The format is too widespread to be coincidence. Is this convention documented somewhere or just packagers adopting it randomly?
Usually such a URL leads to the main upstream development branch. However for the context of the spec file it might be interesting to also specify the exact tag or commit the package is about. With that information one could simplify importing patches to git before rebase to a new version.
So in case of kmod the spec file could have:
#Git-Tag: v30
It's probably people cribbing off each other. I don't know of anything that uses that stuff. There's certainly nothing documented to work that way. -- 真実はいつも一つ！/ Always, there's only one truth!
On Thursday 2022-09-29 15:12, Ludwig Nussel wrote:
Some spec files contain commented pseudo tags like e.g
#Git-Web: http://git.kernel.org/?p=utils/kernel/kmod/kmod.git;a=summary #Git-Clone: git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod
The format is too widespread to be coincidence. Is this convention documented somewhere or just packagers adopting it randomly?
When one does so much in a distro that one already counts as (plural) packagers... Thanks for the vote of confidence :D
Usually such a URL leads to the main upstream development branch. However for the context of the spec file it might be interesting to also specify the exact tag or commit the package is about. With that information one could simplify importing patches to git before rebase to a new version.
As the originator of those two lines, I did not have much in mind but two use cases. First, a corollary: * When a _service file exists, the branch is in _service. Else, the "branch" is in the Version:/Source: line so to speak. The two use cases: a. Downloading the entire codebase with entire history to search for and/or extract a bugfix/patch/CVE. Or to curate a SUSE-level changelog from a bunch of loose commits. That's the Git-Clone line. b. Determine the newest version (tag). On Github, I can subscribe to notifications about annotated tags. But some projects are not on Github and some more projects are not using annotated tags (even though they should). I occassionally revisit `osc my pkg`, i.e. manual intervention, and then want to find the newest version so I can transplant it into the Version:/Source: field or the version field of a _service file when that is in use. A gitweb serves that purpose because it shows the tags in descending-date order. Cloning the entire repository is not desired. That's the Git-Web line. If absent, implicitly equal to Git-Clone. Ideally, we could have something like https://manpages.debian.org/stretch/devscripts/uscan.1.en.html for Git-Web but openSUSE does not, so that's that. (openSUSE has a freshcode.club bot, but few people seem to use that service ever since the predecessor, freshmeat, had shut down.)
participants (3)
-
Jan Engelhardt -
Ludwig Nussel -
Neal Gompa