The file reading part refactored to a (more) generic helper in PR #886
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Nothing against adding -f support, but this adds third variant of essentially
the same code that is in readFilesManifest() and addFileToTag(), with its own
pecularities (at least missing %__file_name macro handling), when we're trying
instead to eliminate these redundancies across the board.
@vathpela Could you adjust the commit message to indicate that both get this
enhancement?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> Wouldn't this also make sense for `%sourcelist` too?
Yeah - and if you look at the code, it does it for both, I just didn't mention
one in the commit message.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Wouldn't this also make sense for `%sourcelist` too?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@vathpela pushed 1 commit.
ef44ff173f42517ebebfe5b31c35e3bd1e9c6388 Make "%patchlist -f patches" work.
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
This adds a -f argument to %patchlist, similar to that for %files.
There is no limit to how many patchlist files you specify, and doing so
does not restrict the use of an inline patch list. Patches get added
from the leftmost list to rightmost, and any patches listed below get
added after that.
