Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
Mark the not-root test as skippable, and skip it if running as root, as
there is no restriction currently to represent that. For the root test
clarify the failing exit code with a comment.
|
|
libtool generated scripts make use of file(1) to detect the executable
types.
|
|
|
|
Using the .dist-version file implies that we need to do a two staged
release process. First a «make dist», unpack the generated tarball
distribution, and run that again. When the deciding factor is the
format of the version. Switch to use that exclusively.
|
|
|
|
Update to 1128t.
|
|
Update to 2970t1f.
|
|
Update to 603t.
|
|
|
|
|
|
This fixes the Depends to what is really required by the configure
script.
|
|
This reduces the required dependencies to a minimum.
|
|
The /dev/null device always has world-writable permissions, so it would
always fail anyway.
Spotted-by: James Clarke <jrtc27@debian.org> (on IRC)
|
|
Several projects use this to bypass the requirement for a matching
option so that they can start a program no matter what. Even though
the check should not fail on this condition, it does on some scenarios,
such as when using Linux user namespaces.
Closes: #920242
|
|
This way we have the entire logic in one place, and can more cleanly
conditionalize on SO_PASSCRED availability.
|
|
Fixes build failure at least on GNU/Hurd.
|
|
|
|
|
|
|
|
Closes: #919040
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
Closes: #917813
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
Closes: #912023, #912024
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
Closes: #915610
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
Supress false positives and intended code usage.
|
|
Having to refer to the documentation to know what these are about is
annoying, inline a brief description.
|
|
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 clear what the variable is all about.
|
|
This makes it easier to guarantee we use the correct size for the
involved variable.
|
|
Warned-by: cppcheck
|
|
|
|
|
|
The introduction of dependency satisfiability for trigger processing,
which was in the original spec but not the implementation, there has
been countless problems with bogus detection of trigger cycles.
The problem is that whenever we try to process triggers for a package,
we might not be able to due to dependency unsatisfiaiblity, which means
we have to put the package back into the queue. If we add the state into
the cycle detection tracker, then multiple visits to these packages will
hit the cycle detection for artificially generated cycles. But we cannot
avoid performing the checks because that will miss dynamic cycles coming
from maintainer scripts, for example.
To avoid most of these problems (while possibly not fixing all potential
ones), we should delay trigger processsing entirely until we have
emptied the processing queue as much as possible. We do that by
introducing a new dependency try level, after the dependency cycle
breaking one.
We will also make the trigger cycle detection unconditional of the
dependency try, because for the trigproc try-queued it will not matter
anymore as we will only ented on higher dependency tries, and for the
other trigproc types we should not care about any queue-specific
dependency try level.
Closes: #810724, #854478, #911620
|
|
We should only reset the cycle detection in case we are not bailing out
from the processing with an error, otherwise we could come back to this
package and detect an artificial trigger cycle.
|
|
This makes the code stop skipping unsatisfiable dependency checks.
|
|
Each of these reasons for processing triggers have different requirements
and attributes:
- The required one, must perform all checks as it is done as part of a
simple loop to guarantee Pre-Depends satisfiability.
- The try-deferred one, must not fail on unsatisfiable dependencies, as
we are doing opportunistic trigger processing, after a normal
processing queue run.
- The try-queued one, must perform all checks and fail hard if any
unsatisfiable scenario occurs.
|
|
We should not leave the package that could be used to make progress by
way of trigger processing in this variable, because it might not have
its dependencies satisfied, which means we'll be trying to process it on
every next loop, and get into artificialy detected trigger cycles.
|
|
This moves the description closer to the type defining its values, which
makes more sense than in the configure function.
|
|
Thiw makes the code way easier to understand as there no magic numbers
anymore. It will also make it trivial to add new levels in-between.
|
|
Once we are giving up on a package that we will stop processing, we need
to mark it as PKG_ISTOBE_NORMAL so that the dependency checks know they
cannot expect this package to be processed anymore. Otherwise we might
end up never detecting that we are not making progress, as we expect to
process this package at a later point, when that will never happen
anymore. This then would end up causing asserts in the process queue
loop.
Closes: #901127, #910819
|
|
|
|
Assign hare->next to hare instead of using the temporary variable, so
that it's quicker to spot as an iterator assignment.
|