- Handle reinstall as a new sub-mode of install, leaving all the
--replacepkgs etc insanity alone, at least for now. For rpm cli we
could probably remap --replacepkgs into proper reinstall, but handling
this in the API is much harder as problem filter flags, such as
RPMPROB_FILTER_REPLACEPKG, are not known at the time packages
are added to transaction, and also we can't very well go and
add new elements to the transaction from inside rpmtsRun()
- Fixes the use-case of RhBug:966715 but not the exact cli invocation
in that bug... that needs something different
- Again, this could've quite easily been done by accepting "r"
as "how" argument to addInstall(), but this makes testing for
rpm support much easier. Otherwise not much to see here...
- Related to RhBug:966715 / RhBug:1071854 ... etc
- Add new public rpmtsAddReinstallElement() function for properly
reinstalling packages within a single transaction, ie one that
behaves like it was upgrade to the same version, removing files
on changed policies (excludedocs etc).
- This could've been done by redefining the "upgrade" argument of
rpmtsAddInstallElement() to an "operation", but as the upgrade
argument accepted values are not clearly defined this could
have unwanted side-effects, plus this way its also easier to test
whether reinstall is supported by rpm.
- Related to RhBug:966715
- Add enumeration for install-style operations
- Refactor the guts of rpmtsAddInstallElement() into an internal
helper operatins around the new enums
- Any functional change by this commit would be a bug...
- Account for packages removed in transaction when checking whether
package is already installed. This permits install + erasure of the
same package within a single transaction, aka reinstall, with
changing file policies (excludedocs, installangs etc) properly
taken into account. Related to RhBug:966715.
- This differs from --replacepkgs which is just a strange hack really
but one that's difficult to change because of how its presented
in the API. --replacepkgs behavior does not change here, and a proper
reinstall is NOT possible when replacepkg problem filter is active.
- Testing this is not possible with rpm cli :(
- Because the check has been missing, these flaws are all over the
place. Duplicates are not really worth breaking existing specs, so just
warn for now, and preserve last one wins-behavior.
- Because of the missing check, multiple empty %files sections could
be abused for the effect of multiple -f arguments back when that
was not supported. The weird corners people find...
- Turn it into a warning and preserve former behavior, except avoid
leaking memory in this case.
- Reword the message to something hopefully little more understandable,
change from error to a warning (only matters for output)
- Check unused macros at end of every scope, but unlike with parametrized
macros, dont actually delete
- Only whine once per unused macro due to the above to avoid spurious
output due to above
- This catches the common error in specs where %define is used in a scope
unintentionally, eg "%{!?foo: %define foo 1}" where the just defined
macro should actually fall out of scope upon the closing }, but
only gets erased if any parametrized macro is "called" and causes
insane behavior such as described in RhBug:552944. So at least we'll
warn on these situations.
- In practise doesn't change anything visible as the "macro not used"
message is disabled, but tracking a flag bit is saner than
strlen() + strchr() + bunch of other stuff which isn't even correct:
prior to this %## would've triggered "unused" errors which is plain
wrong, and complaining about unused %1 %2 ... isn't really right
either.
- The checking from commit 89ed8009eb was
woefully broken and inadequate, due to the way these puppies are
storen in the header. We need to actually look up language presence
in i18ntable and work from there.
- Revert back to pre commit c22d5b1299
state wrt macro substitution. The commit does have fixes we want
but it also breaks valid cases which is not okay. We really need
a far more thorough macro test suite before these kind of changes,
and also need to do the changes in more controlled pieces.
- Commit c22d5b1299 changed the parsing
to require a valid name in %{name} macro, but this outlaws existing
uses such as %{foo_%{bar}_something}. Relaxing the %{name} form
to use as-is substitution as well allows these to work again.
- Makes the testcase from commit f082b5baa4
succeed. While the old behavior is non-sensical and most likely entirely
unintentional, we're changing a very long-standing behavior here (tested
back to rpm 4.4.x and almost certainly much much older than that) so
its entirely possible people are actually relying on the old
behavior. Lets see what breaks...
- Should've really been in commit 20cfa7d2b4
but at the time NSS didn't even support SHA-224 so it was untestable.
Now that it does, and somebody actually bothered to test...
Fixes RhBug:1066494.
- While there's nothing wrong with packages with no files, a manifest
file with no files is likely to be an error or mistake of some
sort and seems worth issuing a warning at least.
- Related to / inspired by ticket #870.
- commit 58c5eb28d5 added the errno
match check, but its only relevant for EINVAL which can be
returned for non-system errors too, the others are always system
errors regardless of what errno might hold at the point we get
to check it.
- HEADERFLAG_SORTED flag bit has been used to track the header
sort state since beginning of times, but the header sort actually
has three different states: truly unsorted (such as after additions),
sorted by index achieved with headerSort(), or sorted by offset which
is creatively called headerUnsort() in the API.
There's exactly one place that requires offset sorting, namely
headerExport(). It does call headerUnsort() explicitly, but
headerUnsort() would not do anything unless the header was in
index-sorted state. This is quite often the case, but data addition
would unset the sorted-flag, and causing headerUnsort() not to
do anything at all when it most certainly should have. That incorrect
sorting caused headerExport() calculations to be wildly off.
This ancient bug was unearthed by the innocent looking
commit eae671556470136c37951f53ca966cd1bd09aac4: prior to that,
in half the cases headerSizeof() used to be called first, causing
index-sorting to take place, after which the headerUnsort() in
headerExport() did the right thing. In the other two cases
headerSizeof() was called afterwards, and the headerExport() would
be garbage in cases where new data had been just added, such as package
installation. With headerExport() eliminating the need to call
headerSizeof() all the cases became broken as the header would
seem much bigger than it is due to the bad sort order and cause
cases like RhBug:953719 where a largish header suddenly appears
to be oversized, causing mysterious install failure. Prior to the
commit (which in itself IS innocent) the issue would've mainly
manifested in cases where the header needs to be rewritten, which
only happens when files are replaced and the header is rewritten for that.
- The region checks for signature header and "regular" header are
identical except for the tag used, this is an obvious pre-requisite
for unifying those.
- This isn't supposed to change any behavior, so if something changes
its likely a bug...
- AFAICT rpm never actually created signature headers with HEADER_IMAGE
as region trailer tag, except when trying to sign V3 packages with
old rpm 4.x versions (newer ones refuse to do so). This region trailer
quirk doesn't actually make such packages work any better, they just
fail in a different way (such as RhBug:517818)
Florian Festi