Age | Commit message (Collapse) | Author | Files | Lines |
|
When we have been requested to load the available file, and that
contains a description for a package that is not installed, we should
use that instead of printing the confusing string stating that the
description is not available.
Closes: #43573
|
|
Several of these are used by the test suite.
|
|
We assign name to p, which we operate on everywhere in this function
except for the first check which we still perform on name. This confuses
at least cppcheck, and it's in any case inconsistent.
Warned-by: cppcheck
Fixes: nullPointerRedundantCheck
|
|
The output on log files must not be localized.
Reported-by: Julien Cristau <jcristau@debian.org>
|
|
In some contexts we need output in the C locale, such as log files.
We add a new versiondescribe_c() that wraps the locale-dependant
versiondescribe() function and switches to the C locale and back
to the previous one before returning.
|
|
This will make it possible to select either the current locale or a
specified one, currently only C is selectable.
We use this because the uselocale(3) POSIX API is recent, and the system
might not have it available, so we might need to fallback to use
setlocale(3) instead, which even though is not thread-safe, it's better
than nothing.
|
|
The variable was written to but never used.
Warned-by: cppcheck
|
|
This is more future proof, and in this particular case it was tripping
over cppcheck and emitting a false positive for constArgument.
Warned-by: cppcheck
|
|
Print the PID of the lock contender, switch the tense to past as the lock
might not be locked anymore by the time we finish, and add a warning
explaining that removing the lock file is never the correct solution.
|
|
This file contains information only valid as long as the downloaded
sources are also available. So it is closer to a cache than a database,
and as such, there is no need for an uncompressed backup, which can
take quite some space.
Closes: #343578
|
|
We should use the correct errno value, otherwise the error string makes
little sense, and ends up being very confusing.
|
|
We need to assign a status value in the non end-of-tape branch,
otherwise we are using an uninitialized value, which might be anything,
and could end up making the code proceed even if the archive is
damaged/broken, etc.
|
|
When we are destroying a tar_entry we need to zero the struct, otherwise
we will end up freeing already freed memory and crashing.
|
|
This will make it possible to have a value denoting an unknown format,
when we initialize the tar_entry or tar_archive structs.
|
|
|
|
There were several error messages involving the dpkg database, that were
ambiguous by referring to it as "dpkg status area", instead of printing
the affected pathname. The historical reason for not being more explicit
has been to keep the user a bit under the dark, because this has been an
internal database storage, and only those in the known would go there to
edit it by hand and similar.
This is a bit pointless though, because the Internet is full of
references to those directories, and other error messages just print
them anyway.
In addition, for users that want to diagnose what is the problem this is
not helpful, and the directory might have been changed at build or run
time with one of the options.
Closes: #883700
|
|
Versions before 1.13.10 did not properly clear the Origin and Bugs
fields, so there might still be entries with these fields that are
not getting garbage collected properly.
Make sure to blank these package entries so that they get forgotten
on the next database dump.
Closes: #922410
|
|
|
|
Closes: #922212
Reported-by: Y <sevener@cock.li>
|
|
We need to do that, as we might try to use args again when constructing
the error message into the emergency buffer, which would get garbage
instead.
|
|
We should compare only the memory being used, and file_slurp() does not
guarantee NUL-terminating the varbuf.
Closes: #920974
Diagnosed-by: Frank Schaefer <kelledin@gmail.com>
|
|
We use a number that is close to the amount of packages currently present
in a Debian suite, so that installed and available packages do not add
tons of collisions.
The memory usage is «BINS * sizeof(void *)», so it will be 256 KiB on
32-bit systems and 512 KiB on 64-bit systems.
Update the code comment to reflect the above.
|
|
Now that we do not use a nickname mapping anymore, the field struct
contains the actual field name matched, so we can report it correctly
instead of listing all possible altrnatives, and then missing some.
|
|
The current code first does a lookup to see if the fieldname is in the
nicknames table, if found fixes up the fieldname to the new alias, and
then always does a lookup for the normalized name in fieldinfos table.
This penalizes the common case (i.e. non-obsolete fieldnames)
substantially. Also moving the nicknames into the fieldinfos table will
allow to print correct fieldnames on error as those are not mangled any
more, and to provide new wrapper parse functions that print warnings for
the obsolete fieldnames.
|
|
Move the error reporting outside the involved functions so that we do
not need to call gettext if there is no error, which has a significant
performance cost.
|
|
Move all field names to be format arguments so that these do not get
accidentally translated. Use fip->name instead of hardcoding the field
name. Always refer to the field names as "'%s' field". Use the proper
field names instead of descriptions. And capitalize their names.
|
|
Although package states are very unlikely to change their names, it's
just better to use a single canonical place to store their values.
This also makes sure no translator will accidentally translate these
names.
|
|
|
|
|
|
These are intended to be used to check performance improvements in the
libdpkg implementation.
|
|
Closes: #920880
|
|
This will make it possible to access the filesystem entries per package
from anything that queries the database, such as «dpkg-query --show».
|
|
We know what we do not support, let's detect and give better diagnostics
so that users get even less confused.
|
|
This makes the tar extractor track and report back parse errors, so that
we can give more descriptive messages.
|
|
|
|
This will make it possible for library users to specify alternative
warning printers.
Prompted-by: Julian Andres Klode <jak@debian.org>
|
|
These are handling a package hash, and db seems to imply some kind of
on-disk storage. Rename the pkgiterator too to pkg_hash_iter to make it
consistent.
|
|
|
|
|
|
|
|
This makes it easier to guarantee we use the correct size for the
involved variable.
|
|
This way we will be able to forcefully disable it.
|
|
Force the output to fully buffered, because originally stdout was
a tty, so it was set as line buffered. This way we send as much as
possible to the pager, which will handle the output by itself.
|
|
If the pager quits early, the parent will receive a SIGPIPE as the write
end of the pipe will not be available anymore. Instead we ignore SIGPIPE
and also EPIPE errors when writing to stdout.
Otherwise if we quit the pager early, the program will exit with an
error code.
Reported-by: Holger Levsen <holger@layer-acht.org>
Ref: #909754
|
|
|
|
This makes it possible to use a dpkg specific pager.
Suggested-by: Craig Sanders <cas@taz.net.au>
Ref: #909754
|
|
There's no point in executing «cat», we are already dumping the contents
to stdout.
|
|
The PAGER environment variable is specified in POSIX as taking a pager
command and any number of arguments to be passed to «sh -c», so we have
to preserve that behavior or this breaks badly on systems where PAGER is
set that way.
This actually gets in the way of improving the pager command presence
detection, but we'll fix that later on, by making the scanning of the
environment variable smarter or by trying to execute the fallbacks.
Closes: #910009
|
|
Let's just handle opening the file and passing its data to the pager
ourselves, as that gives us more control, and then can decide not to
run a pager at all, and do not need to mess with arguments which might
need to be passed to «sh -c».
|
|
This module handles setting and getting the filesystem root directory.
|