Issue FS#24230. If a symlink is broken and included in the removal
process of a package, we blew up and segfaulted due to
alpm_compute_md5sum() returning NULL and then performing a strcmp()
operation.
Signed-off-by: Dan McGee <dan@archlinux.org>
Don't call os.stat() when we should be using os.lstat(); this allows us
to actually test dead symlinks that don't have a corresponding file. Add
a new LINK_EXIST rule that complements FILE_EXIST for a similar purpose.
Signed-off-by: Dan McGee <dan@archlinux.org>
The vercmptest script needs to be invoked as a bash script for this to
be valid; the -p operator is interpreted as an argument to look up by
sh. This goes way back to commit 3bf9448943, done to solve
http://mailman.archlinux.org/pipermail/pacman-dev/2008-July/007180.html.
Saw this problem running in a virtual machine where sh is not bash, but
in fact dash:
user@debian-powerpc:~/projects/pacman$ ./test/util/vercmptest.sh
src/util/vercmp-p: not found
src/util/vercmp is src/util/vercmp
vercmp binary (src/util/vercmp) could not be located
Signed-off-by: Dan McGee <dan@archlinux.org>
Noted in FS#23342. When the user attempts to install an ignored package
and answers no when asked whether to install it, pacman bails out with:
"error: target not found: packagename"
This is because satisfiers are not found for the package and execution
continues to process_group(), where the package is treated as a group
(which does not exist).
In addition, test ignore006.py is updated with PACMAN_RETCODE=0 since
saying no to installing an ignored package should not be considered an
error.
Signed-off-by: Pang Yan Han <pangyanhan@gmail.com>
Signed-off-by: Xavier Chantry <chantry.xavier@gmail.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
I managed to just make deptest001.py fail by changing a DEBUG-level
logger in commit b12be99c89. This should not be this fickle. Enhance the
OUTPUT rule to use an actual Python re object when looking for matches,
and make a lot of the rules use stronger patterns to match with.
Signed-off-by: Dan McGee <dan@archlinux.org>
This case currently fails, but highlights a failure in our install
process I experienced the other day. Because we don't do replacement
uninstalls inline with the rest of the upgrade uninstalls, we can have a
time on our system where a critical package is not installed.
I hope no one ever renames glibc.
Signed-off-by: Dan McGee <dan@archlinux.org>
This allows error messages emitted by the frontend to be a bit more
descriptive and not have the annoying "well why didn't you tell me that
the first time" problem. If a package had multiple missing deps, we
would bail on the first one before rather than finish processing all
missing dependencies, and only print one error message. Instead,
continue through this entire set of missing deps and append all eventual
errors.
The added pactest tests this case, as the to be installed package has
two missing dependencies. However, pactest does not actually test or see
the difference in output from before and after, so it passes in both
cases, but it is clearly visible in the logs.
Signed-off-by: Dan McGee <dan@archlinux.org>
-d skips checking the version of a dependency.
-dd skips the whole dependency check.
Signed-off-by: Xavier Chantry <chantry.xavier@gmail.com>
Signed-off-by: Florian Pritz <bluewind@server-speed.net>
Signed-off-by: Dan McGee <dan@archlinux.org>
No reason to disallow this- it allows keeping even more packages around in
the cache. Test cases included for this case and to ensure the default
behavior is preserved.
Signed-off-by: Dan McGee <dan@archlinux.org>
The first two are rather standard tests of our two available clean options,
and the third is attempting to test a reported bug (and failing to make the
given case fail).
Signed-off-by: Dan McGee <dan@archlinux.org>
This uses the new public functions to handle targets from the frontend,
like it used to be :
1) alpm_find_dbs_satisfier to find (optionally versioned) package or
provision
2) alpm_find_grp_pkgs to find members for a groups
3) alpm_add_pkg to finally add the pmpkg_t from 1 or 2
Of course, this adds more code to the frontend, but it completely
deprecates sync_target and sync_dbtarget interfaces.
This all-in-one interfaces felt wrong and left no control to the
frontend. A good frontend should just use alpm_add_pkg, with pkg coming
from alpm_db_get_pkg (for normal targets), alpm_find_dbs_satisfier (for
versioned provisions) or alpm_find_grp_pkgs (for groups).
This also opens the way to provide a better group handling in pacman
without constraint from libalpm and callbacks.
In ignore006, only the retcode changes, because no package was found to
satisfy the target (the only possible package is ignored).
Signed-off-by: Xavier Chantry <chantry.xavier@gmail.com>
If there are multiple providers in one db, pacman used to just stop at
the first one (both during dependency resolution or for pacman -S
'provision' which uses the same code).
This adds a new conversation callback so that the user can choose which
provider to install. By default (user press enter or --noconfirm), the
first provider is still chosen, so for example the behavior of sync402
and 403 is preserved. But at least the user now has the possibility to
make the right choice in a manual run.
If one of the provider is already installed, it is picked for
reinstall/upgrade, so that provision 002/003 pactest now pass.
$ pacman -S community/smtp-server
:: There are 3 providers available for smtp-server:
1) courier-mta 2) esmtp 3) exim
Which one do you want to install?
Enter a number (default=1):
Signed-off-by: Xavier Chantry <chantry.xavier@gmail.com>
We were piecemeal passing fields from the test object in and it was getting
out of hand, and future work would have added yet another argument. Instead,
just pass the entire test object and entrust the rule to get what it needs.
Signed-off-by: Dan McGee <dan@archlinux.org>
These deal with already-installed packages and how they should be the
preferred provider in cases where provider selection now occurs. A few
involve multiple sync repos.
Signed-off-by: Dan McGee <dan@archlinux.org>
The order was non-deterministic before, and just happened to work for
sync023.py as it was written. Ensure there is some sort of predictable
ordering.
Signed-off-by: Dan McGee <dan@archlinux.org>
Remove all logic dealing with PKG_MODIFIED as this rule no longer exists.
This removes a bunch of unnecessary stat and checksum logic that most of the
time we were never even using. Also update the file modified checks to mark
every file created using mkfile() with an older time so any modified checks
will just work without hacks.
Signed-off-by: Dan McGee <dan@archlinux.org>
All conditions that this particular rule tested are better served by using a
more specific rule, whether that be checking a package version or whether
files inside the package have changed or still exist.
Signed-off-by: Dan McGee <dan@archlinux.org>
Instead, go the same route we have always taken with version-release in
libalpm and treat it all as one piece of information. Makepkg is the only
script that knows about epoch as a distinct value; from there on out we will
parse out the components as necessary.
This makes the code a lot simpler as far as epoch handling goes. The
downside here is that we are tossing some compatibility to the wind;
packages using force will have to be rebuilt with an incremented epoch to
keep their special status.
Signed-off-by: Dan McGee <dan@archlinux.org>
Adapting from RPM, follow the [epoch:]version[-release] syntax. We can also
borrow some of their parsing code for our purposes (thanks!). Add some new
tests to our vercmp shell script tester for epoch comparisons, and then make
the code work with these newfangled epoch specifiers.
Signed-off-by: Dan McGee <dan@archlinux.org>
Confirming the current behavior. And yes, the error message is still no
better than it was when this was reported 3.5 years ago.
Signed-off-by: Dan McGee <dan@archlinux.org>
These are probably useful anyway, but also exposed the double file list bug
that will be fixed in a later commit.
Signed-off-by: Dan McGee <dan@archlinux.org>
This will prevent duplicates, which we had plenty of once I made a few tests
that had a list of files greater than the normal two. The previous logic was
not working quite right.
Signed-off-by: Dan McGee <dan@archlinux.org>
* FS#19854 (--ignore is ignored with groups)
* http://www.archlinux.org/pipermail/pacman-dev/2009-June/008847.html
(operation aborts when a package from a group is ignored/and user chooses
not to install it)
If a group member is ignored, we expect
a) a question whether to install
b) after saying 'no' to a), the ignored member not to be installed
c) all other group members to be installed
d) pacman to execute successfully
Signed-off-by: Dan McGee <dan@archlinux.org>
(cherry picked from commit 9d0b33fd33)
This creates two packages with extremely long description lines (500KB and
600 KB), causing our archive read code to perform reallocation to store the
whole contents. One of the packages will successfully read while the other
will fail for the time being.
Signed-off-by: Dan McGee <dan@archlinux.org>
And modify the code to not print the full rule string if it is more than 40
characters long; truncate it instead.
Signed-off-by: Dan McGee <dan@archlinux.org>
When a -Sk or -Uk operation induced a removal of an existing local
package, --dbonly was not in effect and the files were all removed.
Fixing this behavior was already marked as TODO in database012 pactest
------------
TODO: I honestly think the above should NOT delete the original les, it
hould upgrade the DB entry without touching anything on the file stem.
E.g. this test should be the same as:
pacman -R --dbonly dummy && pacman -U --dbonly dummy.pkg.tar.gz
------------
Signed-off-by: Xavier Chantry <chantry.xavier@gmail.com>
[Dan: small coding style touchup]
Signed-off-by: Dan McGee <dan@archlinux.org>
