| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Change-Id: Ifd629ba679a11ede4d831195c6aea2245efc3300
Signed-off-by: biao716.wang <biao716.wang@samsung.com>
|
|
A) use RPMTAG_SUGGESTS and RPMTAG_ENHANCES to store them.
This is different to upstream, which uses RPMSENSE_MISSINGOK
and RPMTAG_REQUIRES/RPMTAG_PROVIDES instead. I chose different
tags because I wanted to be compatible. The point is that
applications that don't know about the new MISSINGOK semantics
will mis-interpret the provides/requires otherwise, which
I deemed to risky.
B) use RPMSENSE_STRONG to support a "strong" version, "Recommends"
instead of "Suggests" and "Supplements" instead of "Enhances".
|
|
- Rpm has traditionally (at least for the last decade) preserved
existing %ghost %config file on erasure. Whether this was intentional
or not, changing the behavior now risks data loss in case people
are relying on this long-standing behavior.
- This fails now: The behavior changed as (an unexpected) side-effect
of commit 389b1ab706be8eddba9f00c7084759f670ce96ac.
(cherry picked from commit 4efec66338ef04d2f1ed20cfba84c47145269d0d)
|
|
- Further parametrize conflicttest.spec to allow for different attributes
- Verify that the real file gets created without conflicts, that
it doesn't get removed when ghost is removed and gets normally removed
on erase.
- This is the case commit a712252392eca75443ca45c10a72873cabec7963 was
supposed to fix (which it does but with, ahem, "slight" side-effects)
(cherry picked from commit 0485eab2c96173d1e34e4edb3570e58a693e255e)
|
|
- Further parametrize configtest.spec to allow for different attributes
- Verify pre-existing %ghost %config is preserved on install,
that it survives upgrades and gets removed on erase.
This fails now because it IS broken due to commit
a712252392eca75443ca45c10a72873cabec7963.
(cherry picked from commit 5121ea2151f13e58740b7b4e7dc20cff5f2475fb)
|
|
- Similar to commit f7c1eb5ef041b9b06cbb81dac7d7972a602cad44 but
on obsoletions
|
|
- Different versions can happen two ways: older first or older last,
test both cases
- Add verbose output for install to get the warning messages too and
require that matches as well
|
|
- Also test for the cases where packages are installed in different
transactions, the outcome should be exactly the same in every case
regardless of the order.
- Change the expected output to something slightly more readable for
us humans
|
|
|
|
- Should've been in commit 0bbcbb050d3a1d93eafa5ee353d4b89a9946b68f
|
|
- Rpm cannot currently *correctly* deal with directory symlink changing
to a directory through updates, detect early and abort with conflicts
instead of proceeding with known-broken results: previously these
would seemingly succeed but without actually doing the requested
changes, and leaving orphans on the disk. Far less evil than the
directory replacement failure but incorrect anyway.
- Same %pretrans wackiness as with directory replacements applies here.
- Adjust test-suite to match the new behavior.
- It's possible there are packages that have been relying on the former
broken "success" results, so this might need further fine-tuning...
|
|
- Rpm cannot currently deal with directory changing to something else
through upgrades. Until now we've barfed up an ugly error in the
middle of transaction, leaving partially installed broken junk behind.
It'd sure be nice to be able to actually handle this some day, but
until then detecting and aborting early is a far better option than
the former behavior.
- There are some "only in rpm" level bizarre quirks here: packages
can work around this limitation by using a %pretrans scriptlet,
which runs before the conflict detection. But this means a possible
test-transaction (as done by eg yum) will still see the conflicts,
as we obviously dont want to run disk-modifying scripts on
test-transaction. So when looking at these removal conflicts, we filter
them out on test-transaction IFF the package has a %pretrans script
so there's a chance it might actually fix the conflict when we get
to it in a real transaction. Obviously %pretrans from any package
could in theory fix such issues, but as this is evil enough as it is,
try to limit the damage... Without %pretrans, the only other option
to get around these is manual intervention.
|
|
- Of particular interest is directory changing to something else
(including the infamous symlink case), which we miserably fail
currently. Until we can somehow manage them someday, we should
abort early (by conflicts) instead of barfing up garbage in
middle of transaction.
|
|
|
|
- Unless the file does not exist on disk, we cannot determine the
correct action for config files and symlinks before we actually
check them. Those are also the only types that *can* result in
FA_ALTNAME/FA_SAVE action, anything else we can just create.
Besides making the logic a whole lot easier to follow, it also
fixes our remaining test-case failures. Who would've thought?
- Might be worth noting that this requires the pile of fsm fixes
from previous commits to work.
|
|
- We already have a carefully precalculated action decided for these
things, use that instead of bunch of arbitrary (except for osuffix)
conditions depending on several nasty hacks and hidden assumptions.
Doing so fixes stuff, who would've thought of that?
- Adjust test-suite expectations
|
|
- Replacing a directory with something else is more complicated than
other cases and deserves tests of its own. For simplicity in
the config cases, remove the "and back" part of the test, and
now this test actually succeeds.
|
|
- Clearly if we have three cats we should be seeing three outputs as well...
|
|
- Besides eliminating another copy-paste variant of the config file
digest calculation and comparison, this fixes the case modified
%config symlink gets silently erased. Unlike a regular config file,
a symlink does not contain a whole lot of carefully tuned data, but
if it's marked %config I think we should honor the %config file rules.
- Adjust test-suite expectations to match the new behavior.
|
|
- Similar treatment as in commit 9f9ed70e2d85b0e8f5e2d9cf9969046034d9ad31,
pay more attention to what kind of files we're comparing in each case,
add a little breathing room and extra comments.
- Handle the case where on-disk link is identical to the one in new
package in which case no backup will be needed, fixing two cases
of unwanted backups in the test-suite.
(similar to commit 7a50e9de80ab3c47618dad1e9a5b2d9b79bfc8dc)
- Other than the on-disk vs new package change, probably doesn't change
anything yet, but prepares us for the next steps.
|
|
|
|
- Several (expected) breakages here too, some backups missing, and
some redundant backups taken
- This is by no means complete set of the possible changes but
gotta start someplace...
|
|
- Several cases are (expectedly) broken here: sometimes backup not
taken when wanted, sometimes redundant backups taken
|
|
|
|
|
|
- Test behavior when installing over a pre-existing file
- Test behavior on erasure
- Two of the erasure-tests are currently failing due to regression
introduced in commit 1845c1d711b88723e596c88e8a7730a360029089
|
|
- When on-disk %config file contents match the contents of the new
package (such as config in old package was buggy, fixed in new
and admin worked around in the meantime) there's no point creating
a backup that's identical to what you already have. Note that
we create the new config anyway instead of skipping as timestamp
might have changed.
- Adjust test-cases to the new saner behavior.
|
|
- This cosmetical only, but there's no point creating the same backup
twice. Depends on commit f7f5f88f9f3d6587e747b034ccb64a3f00ff4e1e.
|
|
- Note we're only checking the contents where backups *should* be
created, not much point checking buggy behavior.
|
|
|
|
- The first tests are kinda redundant but extra tests never hurt anybody...
|
|
|
|
- Currently unused but to allow for testing further cases with the
same base spec...
|
|
- When an existing config file content changes between package versions
but the file has already been changed to match the content of the
new version, we still create a backup file that's identical
to the one that ends up being installed. This is a bug of sorts,
but documenting the existing behavior before changing it.
|
|
- Test for actual file content
- Also clean up any .rpm[new|save|orig] files from the testroot
|
|
- Prior to commit f7f5f88f9f3d6587e747b034ccb64a3f00ff4e1e, this
would've failed: removing the last package to be installed would
cause timestamp failure on all others. The order is arbitrary in
this testcase but it matters in real-world situations such as
secondary arch packages.
|
|
|
|
|
|
- In particular (aside from basics working) we're interested in
the broken symlink behavior: at least glibc and Solaris have
a weird glob() which doesn't return broken symlinks at all,
yet we need to be able to package them (and that's why rpm
carries its own copy of a differently broken, old glibc glob)
- Also test for directory-only match (RhBug:505995 cases)
|
|
|
|
- Add pile of further tests for the more common constructs,
collect various (old and new) corner cases from bugzilla.
|
|
- Previous test only used a single file and no package-specific
directories, now we have multiple files and multiple directories,
some owned by the package and some not.
- This test fails right now due to previously unnoticed regression
in commit 1845c1d711b88723e596c88e8a7730a360029089
|
|
- One test for the normal situation where identical basenames are
not a problem, and another one where this causes a self-conflict
because of a directory symlink.
|
|
|
|
- Rpm traditionally insists on putting itself into /bin and expects
to find various things, especially /bin/sh there as well. This
is normally the case, but on systems where the host /bin is symlink
to eg /usr/bin, the test-suite /bin will be empty except for rpm
itself causing a big number of bogus test-suite failures. Making
test-suite root bin/ always a symlink to $(bindir) avoids this issue
and works whether the host /bin is a real directory or not.
|
|
- /proc, /sys and especially selinux directories are mostly Linux
creatures and even those vary between versions. Use if to avoid
the error code "leaking" in case the last directory is not present.
|
|
- The test-root has a shell but rpm doesn't know about it, add a
fakeshell metapackage that provides it. Should come in handy for
other cases as well, up to now we've been limited to lua scripts only.
- Test that all the "normal" scripts get executed, in expected order
and with expected arguments, on install, upgrade and erase.
- This would've saved the rather embarrassing breakage with commit
274dbf557d1cac90f7c278f9b6d6af05997d92df at least, but better
late than never as they say... It also serves to highlight and
document the arguably broken arguments to %pre- and %posttrans
scripts (ie always 0)
|
|
- Commit ac0ab016a5ec31e65eb0c0910a5a6f1199aae3e7 unintentionally
changed the order of the problems shown in verify strings due to
a dumb oversight (greetings to self, duh). In other words, this
fixes a verify output regression in rpm >= 4.9.x by restoring
the long-standing (and documented) order of the verify output chars.
- Also fix the testcase which unfortunately was only added after
the output-changing commit so it didn't catch the breakage either :-/
|
|
|
|
|
