Don't just set the flag variables to zero length strings, actually unset
them from the environment. This fixes issues with broken gnu Makefies
that use ?= for assigment, where the presence of a var is enough to make
this condition avoid assignment.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
- Properly read each sorted line into a new array, instead of breaking
on every word.
- LC_COLLATE should apply to the sort portion of the pipeline, not the
printing.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
This gives us some amount of room to grow in case we ever find another
reason that we might return with an error from the progress callback.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
We lost some of this output in the fetch->curl conversion, but I also
noticed in FS#25852 that we just lack some of this useful information
along the way.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
_alpm_filecache_setup() destroys the list of cachedirs when it finds no
writeable directories in the config. This put us in an awkward situation
where _alpm_filecache_find() would locate a downloaded file in a r/o
cachedir, but then fail to install it after _alpm_filecache_setup() is
called (with a NULL argument). Change this behavior to merely prepend
the temporary directory to the list of available cachedirs.
Dan exposed it in e07547ee4e, as now a package can be found in a
directory we may not be able to actually store packages in.
Reported-by: Rémy Oudompheng <remy@archlinux.org>
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
Neither deltas nor filename attributes are ever present in the local
database, so we can remove all of the indirection for accessing these
attributes.
Signed-off-by: Dan McGee <dan@archlinux.org>
Put all the callback stuff in alpm.h in one spot, and make the following
renames for clarity with the new structure:
ALPM_TRANS_EVT_* --> ALPM_EVENT_*
ALPM_TRANS_CONV_* --> ALPM_QUESTION_*
ALPM_TRANS_PROGRESS_* --> ALPM_PROGRESS_*
alpm_option_get_convcb() --> alpm_option_get_questioncb()
alpm_option_set_convcb() --> alpm_option_set_questioncb()
Signed-off-by: Dan McGee <dan@archlinux.org>
This was just disgusting before, unnecessary to limit these to only
usage in a transaction. Still a lot of more room for cleanup but we'll
start by attaching them to the handle rather than the transaction we may
or may not even want to use these callbacks.
Signed-off-by: Dan McGee <dan@archlinux.org>
The call to apply was tucked inside validate, and the EVENT callbacks
were done outside the function rather than inside. Reorganize things a
bit to make more sense.
Signed-off-by: Dan McGee <dan@archlinux.org>
This also renames '--receive' to '-recv-keys' to match the wrapped gpg
option name, rather than invent a new one, now that the calling
convention is the same.
Signed-off-by: Dan McGee <dan@archlinux.org>
We were using the mystical [<foobar>] options which is some sort of
cross between a <required> argument and an [optional] one. Remove this
madness and do some other general cleanup/consistency work in the
manpage.
Signed-off-by: Dan McGee <dan@archlinux.org>
We currently have csize, isize, and size concepts, and sometimes the
difference isn't clear. Ensure the following holds:
* size (aka csize): always the compressed size of the package; available
for everything except local packages (where it will return 0)
* isize: always the installed size of the package; available for all
three package types
Signed-off-by: Dan McGee <dan@archlinux.org>
This removes the last usages of this rule that aren't explicitly looking
at real output from pacman. Notably, these tests depended on one
particular debug logger not ever being changed, which is too fragile,
not to mention doesn't work at all with --nolog.
Signed-off-by: Dan McGee <dan@archlinux.org>
This will work fine on x86_64 (or any platform that has a 64 bit long),
but currently fails on i686. This test also stresses the recent changes
to accommodate package size values greater than a 32 bit UINT_MAX.
Signed-off-by: Dan McGee <dan@archlinux.org>
The regex wasn't rooted at the end of the filename, nor was it matching
a period/dot before the file extension. The end result was this matched a
file named '07_all_sig.patch' which is totally broken.
Signed-off-by: Dan McGee <dan@archlinux.org>
Call strlen earlier in the dl progress callback, and reuse this length
to replace some heavier str*() calls with more optimized mem*()
replacements. This also gets rid of a false assumption that the ending
string will ever be longer than the original string.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
Read the entire variable, respecting escapes, which are necessary to
retain for the successive eval.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
Further improvments on 2ca27ab which will allow the changelog and
install script files to contain whitespace.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
Broken in 2ca27a by me, trying to fix another problem.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
This allows local signing of a given key to help establish the web of
trust rooted at the generated (or imported) master key.
Signed-off-by: Dan McGee <dan@archlinux.org>
This enables pacman-key, during --init, to generate a single secret key
for the pacman keyring if one is not present. This will be used as the
root of the web of trust for those that do not wish to manage it with
their own key, as will be the default.
This does not preclude later adding other secret keys to the keyring, or
removing this one- we simply ensure you have at least one secret key
available.
Signed-off-by: Dan McGee <dan@archlinux.org>
This upgrades the simple 15/17 scaling by package number we used before
to package sized based scaling, which is much more accurate. Addresses
some of the issues raised in FS#25817.
Signed-off-by: Dan McGee <dan@archlinux.org>
When the database is locked, sync operations involving transactions, such as
pacman -Syy, show the following:
:: Synchronizing package databases...
error: failed to update core (unable to lock database)
error: failed to update extra (unable to lock database)
error: failed to update community (unable to lock database)
error: failed to update multilib (unable to lock database)
error: failed to synchronize any databases
Whereas pacman -U <pkg> shows:
error: failed to init transaction (unable to lock database)
if you're sure a package manager is not already
running, you can remove /var/lib/pacman/db.lck
Which is much more meaningful, since the presence of db.lck may indicate an
erroneous lockfile instead of an ongoing transaction.
Improve the error messages for sync operations by advising the user to remove
db.lck if he is sure that no package manager is running.
Signed-off-by: Pang Yan Han <pangyanhan@gmail.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
We were using atol(), which on 32 bit, cannot handle values greater than
2GiB, which is fail.
Switch to a strtoull() wrapper function tailored toward parsing off_t
values. This allows parsing of very large positive integer values. off_t
is a signed type, but in our usages, we never parse or have a need for
negative values, so the function will return -1 on error.
Before:
$ pacman -Si flightgear-data | grep Size
Download Size : 2097152.00 K
Installed Size : 2097152.00 K
After:
$ ./src/pacman/pacman -Si flightgear-data | grep Size
Download Size : 2312592.52 KiB
Installed Size : 5402896.00 KiB
Signed-off-by: Dan McGee <dan@archlinux.org>
We only updated if the percentage incremented and enough time had
elapsed, even though the numerator of the current/howmany fraction may
have changed. Ensure we proceed with the progress bar update in these
cases so as to not mislead the user.
Signed-off-by: Dan McGee <dan@archlinux.org>
Any option that flips UPDATEDB=1 doesn't work right now due to what we
thought was a good idea in commit cab1379a1a. Fix this by not
including the update operation in the option count and special casing
it where necessary.
Also, bring back the helpful "Updating trust database" message.
Signed-off-by: Dan McGee <dan@archlinux.org>
Running the pacman test-suite in a non-English locale results in a few
failures. Force the test-suite to run with LC_ALL=C.
Signed-off-by: Allan McRae <allan@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
This reduces from 5 to 3 the number of searches needed on the string
looking for a comparison operator, since we can so a second quick
comparison looking for '=' if we find '<' or '>'. It also makes every
search doable with strchr() or memchr() rather than the slower strstr()
method.
In testing, only 10% of splitdep calls (~1600 / 16000) during an -Ss
database load found a version comparison operator, so optimizing the not
found path to be require less work makes sense.
Signed-off-by: Dan McGee <dan@archlinux.org>
This actually does something in a scriptlet we can check with our normal
set of rules, rather than relying on pacman debug output.
Signed-off-by: Dan McGee <dan@archlinux.org>
If we fell through to the ALPM_DEP_MOD_ANY case, ptr would be NULL, and
we would pass (0 - <str>), which is a rather large negative number or
bogus positive number, depending on signed/unsigned. Just use strdup in
the case where we don't have a ptr available.
Signed-off-by: Dan McGee <dan@archlinux.org>
Hard to believe there was still more room to improve on this, but I
found an easily correctable oversight tonight. Our databases (both sync
and local) contain many blank lines, and we were not moving onto the
next line right away in these cases; instead we would proceed through
our strcmp() conditional checks as normal.
Some local numbers follow to show the effects of this patch:
Sync `-Ss foobarbaz`:
71,709 blank lines skipped early
~1,505,889 strcmp() calls avoided (21 per line)
~15% speed improvement (.210 --> .179 sec)
Local `-Qs foobarbaz`:
6,823 blank lines skipped early
115,991 strcmp() calls avoided (17 per line)
~6% speed improvement (.080 -> .071 sec)
Signed-off-by: Dan McGee <dan@archlinux.org>
Add new alpm_pkg_get_origin() method, use it in the front end now that
the enum constants are publicly available.
Signed-off-by: Dan McGee <dan@archlinux.org>
libalpm now exports type alpm_pkgfrom_t in alpm.h, which may be used
by frontends.
Pacman now uses alpm_pkgfrom_t instead of replicating that type (pkg_from
as was in src/pacman/package.h)
Updated API change in README.
Signed-off-by: Diogo Sousa <diogogsousa@gmail.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
This adds a add_gpg_conf_option() helper function which tries to be
intelligent and only add not found options, and those which have not
been explicitly commented out.
The new options added are 'no-greeting', 'no-permission-warning', and a
default 'keyserver'.
Signed-off-by: Dan McGee <dan@archlinux.org>
* secring.gpg can be 600, readable by root user only
* ensure grep for lock-never option in check_keyring doesn't catch comments
Signed-off-by: Dan McGee <dan@archlinux.org>
The HoldKey option was undocumented and was not suited for pacman.conf.
Instead use the file "/etc/pacman.d/gnupg/heldkeys" to contain a list
of keys not to be removed from the pacman keyring with the --populate
option.
Signed-off-by: Allan McRae <allan@archlinux.org>
After most operations that touch the keyring, it is a good idea to
always run a check on the trustdb as this prevents gpg complaining
on later operations.
Inspiration-from: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
The optimization of only importing keys that were not to be later
revoked was a not smart enough. For example, if a key was
in both a repos keyring and its revoke list, alternate runs of
pacman-key --populate would add then remove the key from the pacman
keyring. This problem is made worse when considering the possibility
of multiple keyrings being imported.
Instead, import all keys followed by the revoking of all keys. This
may result in a key being added then revoked, but that is not much of
an issue given that is a very fast operation.
Signed-off-by: Allan McRae <allan@archlinux.org>
