The point of this early compare to NULL byte check was so we could bail
early and skip the strcmp() call. Given we weren't doing the check
right, this never exited early. Fix it to work as intended.
Noticed-by: Pepe Juárez <trulustapa@gmail.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
This is a trivial operation that doesn't require calling a function over
and over- just do some math and indexing into a character array.
Signed-off-by: Dan McGee <dan@archlinux.org>
This gives us a bit more control and over the archive reading process,
and a bit less is done behind the scenes. It also allows us to use
fstat() in preference to stat(), which should avoid some potential race
conditions.
Some reorganization is necessary to move the stat calls after the open()
calls. Error handling and cleanup in general is also improved, as we had
several potential memory and file handle leaks before in some error
paths.
Signed-off-by: Dan McGee <dan@archlinux.org>
This removes an unnecessary level of buffering. We are not doing
line-based I/O here, so we can read in blocks of 8K at a time directly
from the file.
Signed-off-by: Dan McGee <dan@archlinux.org>
Replacing the strdup when after the first NULL check assures that we get
continue with payload->remote_name defined.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Dan: fix mask calculation, add it to the success/fail block instead.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
This takes the place of three previously used constants:
ARCHIVE_DEFAULT_BYTES_PER_BLOCK, BUFFER_SIZE, and CPBUFSIZE.
In libarchive 3.0, the first constant will be no more, so we can ensure
we are forward-compatible by removing our usage of it now. The rest are
unified for consistency.
By default, we will use the value of BUFSIZ provided by <stdio.h>, which
is 8192 on Linux. If that is undefined, a default value is provided.
Signed-off-by: Dan McGee <dan@archlinux.org>
Doesn't do a whole lot of good to compare against values that are never
set. Fixes bug where -vvv output wasn't grouping packages together
properly.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
There aretwo seperate issues in the same block of file conflict
checking code here:
1) If realpath errored, such as when a symlink was broken, we would call
'continue' rather than simply exit this particular method of
resolution. This was likely just a copy-paste mistake as the previous
resolving steps all use loops where continue makes sense. Refactor
the check so we only proceed if realpath is successful, and continue
with the rest of the checks either way.
2) The real problem this code was trying to solve was canonicalizing
path component (e.g., directory) symlinks. The final component, if
not a directory, should not be handled at all in this loop. Add a
!S_ISLNK() condition to the loop so we only call this for real files.
There are few other small cleanups to the debug messages that I made
while debugging this problem- we don't need to keep printing the file
name, and ensure every block that sets resolved_conflict to true prints
a debug message so we know how it was resolved.
This fixes the expected failures from symlink010.py and symlink011.py,
while still ensuring the fix for fileconflict007.py works.
Signed-off-by: Dan McGee <dan@archlinux.org>
These should all prevent installation, and yet two of the three tests
currently fail. Not good.
The best way to see what is going on here is to diff the three new tests
side by side- there is only a small difference between the three tests,
and that is in the destination of the symlink in question that should
never be overwritten.
symlink010.py: myprogsuffix -> myprog
symlink011.py: myprogsuffix -> broken
symlink012.py: myprogsuffix -> otherprog
Signed-off-by: Dan McGee <dan@archlinux.org>
There is some pecular behavior going on here when a package is loaded
that has no files, as is very common in our test suite. When we enter
the realloc/sort code, a package without files will call the following:
files = realloc(NULL, 0);
One would assume this is a no-op, returning a NULL pointer, but that is
not the case and valgrind later reports we are leaking memory. Fix the
whole thing by skipping the reallocation and sort steps if the pointer
is NULL, as we have nothing to do.
Note that the package still gets marked as 'files loaded', becuase
although there were none, we tried and were successful.
Signed-off-by: Dan McGee <dan@archlinux.org>
First, use fstat() in preference to stat() since we already have an open
file handle. This also removes the need to check for a symlink as that
is not possible when a file is opened.
Next, use archive_entry_mode() rather than archive_entry_stat() as we
only use the mode portion of the stat struct and the call is much
cheaper. Also delay it until it is necessary.
Signed-off-by: Dan McGee <dan@archlinux.org>
Extend the return values of compute_download_size to allow callers to
know that a .part file exists for the package.
This extra value isn't currently used, but it'll be needed later on.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
The fix for -Wl,--as-needed in commit b0f9477f assumes that
--as-needed/--no-as-needed is the only option given in a -Wl line.
However, it is perfectly valid to specify multiple flags comma
separated after a single -Wl (e.g. the default LDFLAGS in Arch
Linux makepkg.conf).
Adjust the fix so it detect --as-needed in a more general context
> readelf -d lib/libalpm/.libs/libalpm.so.?.?.? | grep NEEDED | wc -l
Before: 13
After: 5
Signed-off-by: Allan McRae <allan@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
Update for libtool-2.4.2 while keeping the fix for --as-needed from
commit b0f9477f.
Signed-off-by: Allan McRae <allan@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
This adds a logger to the CURLE_OK case so we can always know the return
code if it was >= 400, and debug log it regardless. Also adjust another
logger to use the cURL error message directly, as well as use fstat()
when we have an open file handle rather than stat().
Signed-off-by: Dan McGee <dan@archlinux.org>
On -R operations, the "New Version" column is always empty, taking up
space and not really showing the user anything valuable. The same is
true on -S or -U operations for the "Old Version" column when packages
are only being installed and not upgraded.
Remove this column so we get a few screen columns back, especially now
that we show repo/packagename style output. This also makes some
adjustment to the padding logic. We no longer include padding in column
widths but it is included in the total table width. We also ensure the
last displayed column is always right aligned, even if this is not the
actual rightmost column.
Example output, before:
$ sudo pacman -R eclipse
checking dependencies...
Targets (1):
Name Old Version New Version Net Change
eclipse 3.7-1 -194.02 MiB
Total Removed Size: 194.02 MiB
And after:
$ sudo pacman -R eclipse
checking dependencies...
Targets (1):
Name Old Version Net Change
eclipse 3.7-1 -194.02 MiB
Total Removed Size: 194.02 MiB
Signed-off-by: Dan McGee <dan@archlinux.org>
This only applies to the VerbosePkgLists option. Lessens the
deficiencies created by earlier work to separate download records by
repository.
Satisfies FS#26334.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
Create a new static function called 'download_single_file' which
iterates over the servers for each payload.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
This is done by both the delta and regular file code, so we can extract
a little helper method. Done mostly to satisfy my "why are we repeating
code here" itch.
Signed-off-by: Dan McGee <dan@archlinux.org>
pkgrel, as with pkgver, simply mustn't contain hyphens.
Signed-off-by: lolilolicon <lolilolicon@gmail.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
Break out the logic of finding payloads into a separate static function
to avoid nesting mayhem. After gathering all the records, download them
all at once.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
These can either be replaced with pm_printf() if they are error related,
or in the fprintf(stdout, ...) case a bare printf() will do.
Signed-off-by: Dan McGee <dan@archlinux.org>
Now that pm_printf() always prints to stderr, we don't need this second
function that was always used with stderr as the first argument. Thus,
this patch removes the function and makes the following sed replacement:
sed -i -e 's#pm_fprintf(stderr, #pm_printf(#g' src/pacman/*.c
Signed-off-by: Dan McGee <dan@archlinux.org>
This matches what we now do in our backend callback function- all
debug/info/warning/error/etc. messages should be on stderr. These are
all the messages with a "warning:" or other type prefix, so does not
affect general pacman output.
This should fix the output confusion noted in FS#26555.
Signed-off-by: Dan McGee <dan@archlinux.org>
The default is supposidely 30 seconds from the gpg manpage, but that
sure wasn't what I was seeing- it was somewhere closer to two minutes of
silence. Add a more reasonable 10 second timeout value which should be
good enough for any keyserver that doesn't totally stink at it's job.
Signed-off-by: Dan McGee <dan@archlinux.org>
The absolutely terrible part about this is the failure on GPGME's part
to distinguish between "key not found" and "keyserver timeout". Instead,
it returns the same silly GPG_ERR_EOF in both cases (why isn't
GPG_ERR_TIMEOUT being used?), leaving us helpless to tell them apart.
Spit out a generic enough error message that covers both cases;
unfortunately we can't provide much guidance to the user because we
aren't sure what actually happened.
Signed-off-by: Dan McGee <dan@archlinux.org>
This logic is reused in both diskspace and downloadspace check
functions, so pull it out into its own static method.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
This function determines if the given cachedir has at least the given
amount of free space on it. This will be later used in the sync code to
preemptively halt downloads.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
We can take a large shortcut here that saves us a lot of time,
especially when upgrading packages with lots of directories. Obviously
iterating the full file list of every single package to determine if
this directory was present in any other package can take quite some time
on a system with many packages installed. We don't need to remove a
directory at all if we are upgrading a package and the version we are
moving to still had the directory.
Also make a small optimization on the package comparsion- we really only
care about equality here, not the result of the compare, so we can
shortcut using our name_hash.
What kind of benefit does this give us? Oh, only a reduction from 295.7
million to 1.4 million strcmp() calls (99.5% fewer) during a
`pacman -S linux libreoffice-common` operation.
Signed-off-by: Dan McGee <dan@archlinux.org>
This is not something that should be used on a frequent basis, and
giving it a short option encourages use without making the drawbacks
obvious. For the 1% of situations that require it, the 5 extra
keystrokes are a fair price to pay.
Signed-off-by: Dan McGee <dan@archlinux.org>
This replaces several printf calls of the following styles:
printf("%s", ...);
printf("some fixed string");
printf("x");
We can use either fputs() or putchar() here to do the same thing
without incurring the overhead of the printf format parser.
The biggest gain here comes when we are calling the print function in a
loop repeatedly; notably when printing local package files.
$ /usr/bin/time ./pacman-before -Ql | md5sum
0.25user 0.04system 0:00.30elapsed 98%CPU
$ /usr/bin/time ./pacman-after -Ql | md5sum
0.17user 0.06system 0:00.25elapsed 94%CPU
$ /usr/bin/time ./pacman-before -Qlq | md5sum
0.20user 0.05system 0:00.26elapsed 98%CPU
$ /usr/bin/time ./pacman-after -Qlq | md5sum
0.15user 0.05system 0:00.23elapsed 93%CPU
So '-Ql' shows a 17% improvement while '-Qlq' shows a 13% improvement on
382456 total files.
Signed-off-by: Dan McGee <dan@archlinux.org>
