Hi,
forgemeta works in release mode, with release archives published over
http(s). It does not talk at all to source projects using the git
protocol (and that is intentional, since a lot ot things tooling-side
do not talk the git protocol and will never talk the git protocol,
starting with rpm itself, spectool, etc).
git is not the only scm system out there. Nor its protocol is set in
stone. It would be very tricky to push it down to layers like spec
files that operate on timescales measured in years/decades and are used
by a huge amount of third-party tools that expect http(s) source URLs.
From a pure auditing side, it is also correct to have all the sources
of things you package listed explicitly, and not have recursive sources
that install themselves other sources behind auditor’s backs.
Note that your spec as it stands is inherently unsafe since you are
pulling sources from a a moving reference (master) instead of commiting
to a specific commit or tag state¹ (another proof git is not safe to
use as direct packaging layer, since it pretends to give you a fixed
state while submoduling things that are not fixed).
The correct auditable way to use git in rpm is to declare all the git
sources you actually use, with a specific tag or commit hash for each
of them.
So you should have a long list of
%forgeurlX
%tagX or %commitX
and a single %forgemeta -a at the end
That will change soonish BTW, I’m currently doing final testing on code
that will use a slightly different syntax:
%forge_urlX
%forge_tagX or %forge_commitX
%forge_patchlist %{expand:
foo1.patch
foo2.patch
}
…
%auto_init
…
%sourcelist
%auto_sources
%patchlist
%auto_patches
%prep
%auto_prep
Because not making -a the default and emphasising -z in the
documentation was comfusing users. -z should be a last resort debuging
help, not the first thing you look at when packaging multiple sources.
That will leave you with each individual source unpacked and patched in
%{_builddir}, and needing a some symlinks between %{_builddir}
subdirectories to construct a unified source trees, but that’s how
multisource works deep down in rpm, nothing I invented myself.
Regards,
¹ I made it work in the macros because I knew people would attempt to
do it, and I’d rather have it work in my code than have people butcher
it to achiever their aims, but from a Fedora packaging guidelines POW
it is a mistake).
--
Nicolas Mailhot
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
