I didn't suggest to apply the patches. That's a different part of the spec and
different spec verbs.
*However* to apply the correct patches to the correct source archive, you need
to know the corresponding patch list. So basically as many “list of patches”
as you can have source archives.
A
Again, this is not about patch *application* at all.
Why on earth would you want to interleave source unpack and patch application?
You can always just unpack all sources first and apply patches afterwards. As
people have been doing with rpm for the 20+ years of its existence.
--
You are
It would be nice to extend the %patchlist concept to have a %patchlist0
(patches to apply after extracting %source0), %patchlist1 (patches to apply
after extracting %source1), etc
That would get one step closer to deprecate the byzantine way %setup expects to
specify patch ordering in
Merged #679 into master.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/679#event-2340075923___
Rpm-maint mailing list
> Can something similar be used for directories?
> E.g.
> %patchdir path/mydir
No. Package contents need to be explicit to avoid random junk from entering
packages.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Can something similar be used for directories?
E.g.
%patchdir path/mydir
will create in ASCIIbetical order for each file in "path/mydir" %patch.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Split the regression fix to a separate PR #682 682 as that needs fixing
regardless of this.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Merging it like that would be just nuts (whole lot of work and pain just to
give packagers even more surprise rope to hang themselves with, no thanks), but
seems I introduced a regression in
commi5fc4e1dd101b27eb8ed9526552c42bb809ac6790 - automatic numbering was
supposed to continue from
@pmatilai pushed 1 commit.
e9a52a9f6012d3998b1c4e6a126ba8d4dfc13bff Continue patch/source autorenumbering
from last specified number
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Why don't we merge them automatically then? Like if Source{1,3,4} are taken and
you supply %sourcelist, it will use Source{2,5,6}.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
One point that isn't maybe so obvious is that both these lists are new spec
sections, and entering a new section means that the preamble has ended. And for
that reason, it's not possible to have more Source[n] or Patch[n] lines (or
anything else belonging to preamble) *after* a %patchlist or
You can combine all the variants if you take care the numbers don't end up
clashing, in which case you'll just get an error on the source/patch number,
like you'd get if you declare two patches with the same number.
I thought about forbidding mixed autonumber and manual numbering but then I
What will happen if you combine SourceX tag and %sourcelist?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Rebased, typo fixed + testcase added.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/679#issuecomment-486602020___
Rpm-maint
Oh BTW, the patch/source autonumbering is not in any released version yet, the
comment about numberless patch/source in the above refers to commit
53036261dda93885106901a983976eb0e9ee6ea2
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view
Patch application is not affected in any way. You can use whatever you like,
although it'd take a special kind of madness to prefer %patch0, %patch1,
%patch2... over %autosetup. Like with numberless Patch and Source, they're
simply autonumbered starting from 0.
I specifically do not want any
@pmatilai also it would be nice to have some extended syntax for this
patchlist, for example `popt-1.16-fix-something.patch,Fix broken
behavior,https://some/pull/request/url` So that it can be inspected by other
tooling.
--
You are receiving this because you are subscribed to this thread.
Same questions as @voxik regarding how sources / patches are extracted /
applied.
Also, would it be possible now to add them dynamically via some Lua magic?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
There is typo in the description which probably comes from
a5ca92f06cbbfd70cec08a87a376ef8c369e00a6 commit message: s/can now we replaced
with/can now be replaced with/
Also, it would be useful to explain how the patches are applied. Is the
%autosetup required? Or should they by applied one by
This introduces two new spec sections, %patchlist and %sourcelist,
which can be used for adding patches and sources by just listing their
names instead of all the tedious Patch[n]: etc boilerplate, you can
just copy-paste file names into the list, the entries are always
autonumbered, eg:
20 matches
Mail list logo
