hi,
On 6/25/20 11:58 PM, Nicolas Mailhot wrote:
> 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).
noted. not clear initially from reading the docs; this helps. thx!
> git is not the only scm system out there.
(snip)
sure. i'm trying to get forge playing nice with not-included-yet hg sources
atm :-)
> From a pure auditing side
...
> Note that your spec as it stands is inherently unsafe since
...
> The correct auditable way
...
(snip)
yup. and for the moment -- while I'm getting my 'end product' sorted out --
that's intentional, and I'm not concerned with audit trail.
yet.
point taken otherwise.
> So you should have a long list of
> %forgeurlX
that's already changed in my latest ...
> %tagX or %commitX
fair enuf, now that the above is nice-n-clear ...
> and a single %forgemeta -a at the end
was having weird artifacts doing that earlier, so split into
one-per-source-target.
once a forge bug (other thread) gets ironed out, that'll get revisited, too.
> That will change soonish BTW, I’m currently doing final testing on code
> that will use a slightly different syntax:
>
> %forge_urlX
(snip)
that'll get announced ... here?
do you have a _rough_ timeframe for when that'll be consistently
supported/usable in rpmbuild, mock & COPR?
bunch of moving parts to get in sync ...
> Because not making -a the default and emphasising -z in the
> documentation was comfusing users. -z should be a last resort debuging
> help
it was helpful for debug, here. and at my early stage, necessary ...
> not the first thing you look at when packaging multiple sources.
yup
> 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.
that's what i'd naively assumed was to cleanly happen when i'd started with
this multisource spec.
if this cleans that up, then +1 !
> ... have people butcher it to achiever their aims ...
but, that's _our_ job! ;-)
cheers.
_______________________________________________
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
