- Work around scoping "fun" wrt nested parametrized macro invocations
combined with macro manipulation from %{lua:...}
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- Similar to "%autosetup -S git", but assumes git-formatted patch files
and hence preserves authorship information and commit messages.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- What was I thinking? Trying to be lazy in a way that only created
more work, and broke with rpmfiles addition in whats most certainly
a non-obvious way. Duh.
- These platform specific scripts haven't been properly maintained
in over ten years, its way past time to get rid of these scripts
that forever confuse packagers as they assume these are actually
being used for something.
- Sure there's theoretical portability loss here, but judging by the
number of updates to these platforms over the last 10+ years... its
indeed theoretical. Any such portability issues just need to be
brought into the world of the "internal" dependency generator finally.
- Replace platform specific find-{requires,provides} scripts with
trivial wrapper scripts that just call rpmdeps with suitable
arguments. This way the generated dependencies using the legacy
external dependency are at least roughly on par with the internal
depgen as, well, they're generated by the same thing.
- Changing from find-{requires,provides} scripts to rpmdeps could
be done by just changing __find_{requires,provides} macros, but
a lot of packages directly refer to the scripts instead so this
way we cover far more ground and in an backwards compatible way.
- In the current macro implementation the check is simply far too
expensive to leave on always. Its useful though, so enable it
when tracing macro expansion, in which case you're probably
troubleshooting some macro-issues...
- Installation of binaries and sources are very different types of
operations, this makes it more obvious when mixing binaries and
sources in -U/-i operation. The progress report for sources is
not identical to binaries but at least it doesn't exceed 100%.
- Combining src.rpm and binary install in the same command is more
likely a mistake than intended, but preserving the functionality
in case somebody relies on it.
- Without this, plugins wouldn't have the slightest clue which package
a %pretrans, %posttrans or %verify script belongs to.
- Whether everything is properly initialized in the %verifyscript context
remains to be seen...
- When the world changes underneath us (eg by %pretrans hackery)
between test-transaction and actual transaction, in some cases
the file action does not get recomputed if already set.
Always reset file actions to FA_UNKNOWN before disposition
calculations to ensure have a clean starting point.
- Perhaps not such a big deal, but this makes rpmPackageFilesInstall()
and rpmPackageFilesRemove() interfaces identical, which could be
useful. In any case there's no particular reason this code should
be in psm either..
- Split the remains into two separate install/erase functions where
the logic is actually far easier to follow. Funny that.
- Since the code heavily relies on using break statement, move it
into a one-shot while loop to avoid having to change it all at once.
- Supposedly no functional changes here.
- Since rc will always be RPMRC_OK from entry to rpmpsmNext(), the
error path can never happen. It might've been possible to activate
in the past where rc was taken from psm->rc but nobody has
missed this particular error in several years so... might as well
axe it.
- Like %pre- and %posttrans, %verifyscript has always been a bit of
an oddball and always received 0 as $1 script argument. It does
seem kinda reasonable to pass the number of installed instances
here too - another note in release notes needed as there are
compatibility implications.
- Test %verifyscript in the scripts argument testcase too
- $1 argument to both %pretrans and %posttrans has been broken (always 0)
since the introduction of these scriptlets. Make them behave like
other scripts, duh.
- In theory its possible this breaks somebody's scriptlets, although its
hard to imagine why anybody would be checking for $1 which always
has value of 0. Anyway, certainly needs mentioning in release notes.
- Update scriptlet test to match the new expectations.
- There are all sorts of strange quirks and associations across
several different tags, sense flags and coded logic scattered
all over the codebase. Begin what's no doubt going to be a long
and arduous process of getting this consolidated into a data
structure.
- Just the trivial basics here, some of it is still unused and various
bits still missing, gotta start someplace...
- Regular scripts can be fetched from headers by tag, but triggers
are all in the same tag set and distinguished by sense flags.
To confuse matters further, tags for all the separate trigger types
do exist but they are only used by librpmbuild, they are never
present in headers. Throw in an "abstraction" that allows covering
these both.
- Defined in bitfield style to make them nicely manipulable, 32 bits
should be plenty enough for different scriptlet types for a couple
of decades more
- Remember the type in rpmscript API + add a getter. Currently derived
from the tag that's passed in, ultimately we'll want it the other
way around but to avoid changing too many things at once...
- (Re)introduced in commit 567b544f34,
headerVerify() may return a message with RPMRC_OK which we want to
pass on if nothing else can be verified, but we need to free the
message if signature/digest checking is done.
Michael Schroeder