| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
A package marked to be on hold, denotes that the package should be kept
in its current version and should not be automatically installed, upgraded
or removed. The same applies to frontends. This behavior does not apply
when the user explicitly requested one of these actions, or the
--force-hold option is used.
It should never prevent dpkg from processing these for configuration (if
they were already in unpacked state) or from trigger processing, otherwise
we might get into trigger loops. Some of the code was already doing this,
but this was not consistently done. We update also the help output and
documentation to clarify the fixed behavior.
Closes: #926472
|
|
This new dependtry level will also check trigger cycles on trigger
process deferral due to unsatisfiable dependencies.
Closes: #928429
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
Initialize the next member when we are allocating the struct.
|
|
Makes its usage more obvious.
|
|
This will prepare the ground for external programs to start using
libdpkg to access the dpkg fsys database via a proper API, instead
of messing with the on-disk layout in so many improper ways.
|
|
We want to stop calling this function from the fsys loading code, so we
should make very sure it is being called before we access the clientdata
members, otherwise we'll just segfault.
|
|
This continues the work to generalize and make these interfaces
available to other users beside dpkg itself.
|
|
The struct filenamenode hash implementation is lightweight, and once
split from the bulk of the on-disk database handling there's no point
in reimplementing it, and then redefining the same struct in multiple
places, which is rather confusing for the reader, and even for static
analyzers.
Closes: #746766
|
|
The problem with assert() is that it does not print the contents of
the variables. It also can be disabled on NDEBUG. But we always want
these consistency checks no matter what, and they are not performance
sensitive anyway.
Enable -Wno-nonnull-compare so that we can keep doing run-time non-NULL
checks in functions, instead of just compile-time checks.
|
|
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
|
|
|
|
If we are not going to process triggers due to an unsatisfied
dependency, we should reset the trigger cycle tracking information
so that we do not end up reporting bogus cycle errors.
Closes: #771730
|
|
Trigger processing on the deferred stage is just opportunistic, but
we enqueue all currently pending triggers that might have been
activated on a previous unpack run, only when being called as
«dpkg --configure pkgname…».
This is a mostly conformant workaround for frontends like apt that do
not correctly call «dpkg --configure -a» or «dpkg --triggers-only -a»
after their normal runs, and leave packages in triggers-pending and
triggers-awaited states.
Closes: #766758
|
|
Trigger processing is sometimes required and sometimes opportunistic.
When trying to make progress on the packages queue, we need to consider
it an error if the dependencies cannot be satisfied in this run. But if
we are running the deferred trigger processing, then we should not fail,
as that's just opportunistic.
Closes: #768852
|
|
Do trigger cycle detection after dependency checks in dependtry <= 1,
and before dependency cycle breaking in dependtry > 1. This makes sure
to always catch trigger cycles, but still gives the opportunity to try
to process triggers for packages that are not yet ready in the first
dependtry, but which might be a bit later on, without wrongly detecting
avoidable and bogus trigger cycles.
Closes: #766557
|
|
The dependencies_ok() function already prints adequate debugging
information, there's no point repeating it in the call site.
Add also a notice() in case we end up forcing the dependency.
|
|
Break dependency cycles on dependtry > 1 in trigproc(), before calling
dependencies_ok(). But if we have a dependency cycle where a package A
awaits triggers and package P has them pending, and both depend on each
other, the dependency cycle breaking code is not smart enough to break
it at the correct place, as the relationship is directional. So we handle
it specially on deppossi_ok_found(), in case we are in the cycle breaking
dependtry. Otherwise we just defer it, but do not record that it can be
fixed by trigger processing, because we would get into an inifite loop.
Move trigger cycle detection after dependency checks, so that it does
not detect bogus trigger cycles that would have been avoided simply by
the dependency checks and cycle breaking code.
Regression introduced in commit 35c1c59cfad75d75b3d98974ad201f95d932adb6.
Closes: #765434, #765668, #765734, #765781, #765789, #765952
|
|
The spec specified this behavior, but the code never abided by it.
Change it now that most of the packages with trigger cycles have been
switched to noawaiting triggers. The rest will make dpkg bail out on
upgrade.
We might need to add appropriate versioned Breaks before the Debian
release to get a smoother distribution upgrade.
Closes: #671711
|
|
This does not give any meaningful information, besides the pointers
being equal or different. Print an actual file or package name instead.
|
|
The standard location <fcntl.h> instead of <sys/fcntl.h> is the
preferred one since a long time (Changelog.old mentions this change
being made in 1996).
This patch fixes the two occurrences that have slipped through, making
the includes consistent with other files in dpkg as well as fixing
compiling on e.g. Android which lacks <sys/fcntl.h>.
Closes: #752036
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
|
|
This gets rid of the need to export the statusinfos and wantinfos
variables from libdpkg.
|
|
|
|
|
|
Fold post_postinst_tasks_core() into post_postinst_tasks(), and replace
open-coded implementation in trigproc().
|
|
|
|
This should help people diagnose problems by providing more context on
what's going on by being explicit about what packages is being handled.
|
|
|
|
This moves the calls near where the package status is being changed,
and makes it obvious that we are creating an update log entry.
|
|
This switches all ad-hoc stderr printing for error notices to the
notice() function.
|
|
These functions have never belonged in the filesdb module, but were put
there temporarily for convenience.
|
|
|
|
|
|
|
|
The colon is often used as a separator but it is always preceded and/or
followed by a space so that it's possible to distinguish between the
colon used as a separator and the colon embedded in a package name
(like in "libc6:amd64").
Based-on-patch-by: Raphaël Hertzog <hertzog@debian.org>
Patch-sponsored-by: Linaro Limited
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
This does not apply for package constructors.
|
|
Replace pkg->set->name with varbuf_add_pkgbin_name(), pkgbin_name() or
pkg_name(). This only changes informative output, so no behaviour change
should result from this.
Based-on-patch-by: Raphaël Hertzog <hertzog@debian.org>
Patch-sponsored-by: Linaro Limited
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
|
|
[hertzog@debian.org:
- Track pkgbin in struct trigfileint. ]
|
|
Use strict types instead of a ‘void *’ pointer.
|
|
Sponsored-by: Linaro Limited
Signed-off-by: Guillem Jover <guillem@debian.org>
|
