apt/apt-pkg/pkgsystem.h, branch 2.7.12Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=2.7.122020-02-26T19:36:52Zapt(8): Wait for frontend and cache lock2020-02-26T19:36:52ZJulian Andres Klodejulian.klode@canonical.com2020-02-26T19:31:03Zurn:sha1:93e1565796b61eb44bec39f50e09a34cbe090178
This is a rework of !6 with additional stuff for the frontend
lock, so we can lock the frontend lock and then keep looping
over dpkg lock.
apt-pkg: default visibility to hidden2020-02-26T19:34:54ZJulian Andres Klodejulian.klode@canonical.com2019-08-13T17:15:19Zurn:sha1:db678df196ccd8f9f6fb336706cf5701d1e53aa6pkgsystem: Drop more virtual workaround shenanigans2020-02-26T13:30:03ZJulian Andres Klodejulian.klode@canonical.com2020-02-26T13:29:06Zurn:sha1:da7de99f8473ae0ac90c90fad3eee80f5f72889aFix typos reported by codespell in code comments2019-07-10T14:15:30ZDavid Kalnischkiesdavid@kalnischkies.de2019-07-10T14:15:30Zurn:sha1:5cfbc5727dba2f4662d24cf4deb7cab7cdd57c14
Also in old changelogs, but nothing really user visible
like error messages or alike so barely noteworthy.
Reported-By: codespell
Gbp-Dch: Ignore
Run unifdef -DAPT_{8,9,10,15}_CLEANER_HEADERS2019-06-12T13:02:55ZJulian Andres Klodejulian.klode@canonical.com2019-05-11T15:17:20Zurn:sha1:daa1352ed3d2bb4bc6aa0f0e7f22be3f0908942dAdd support for dpkg frontend lock2018-08-07T13:07:52ZJulian Andres Klodejak@debian.org2017-01-29T12:05:18Zurn:sha1:c2c8b4787b0882234ba2772ec7513afbf97b563a
The dpkg frontend lock is a lock dpkg tries to acquire
except if the frontend already acquires it.
This fixes a race condition in the install command where the
dpkg lock is not held for a short period of time between
different dpkg invocations.
For this reason we also define an environment variable
DPKG_FRONTEND_LOCKED for dpkg invocations so dpkg knows
not to try to acquire the frontend lock because it's held
by a parent process.
We can set DPKG_FRONTEND_LOCKED only if the frontend lock
really is held; that is, if our lock count is greater than 0
- otherwise an apt client not using the LockInner family of
functions would run dpkg without the frontend lock set, but
with DPKG_FRONTEND_LOCKED set. Such a process has a weaker
guarantee: Because dpkg would not lock the frontend lock
either, the process is prone to the existing races, and,
more importantly, so is a new style process.
Closes: #869546
[fixups: fix error messages, add public IsLocked() method, and
make {Un,}LockInner return an error on !debSystem]
Drop cacheiterators.h include2017-07-12T11:56:05ZJulian Andres Klodejak@debian.org2017-07-12T11:42:18Zurn:sha1:c46f94aa48a9707668c46118b3eec77ff318b78c
Including cacheiterators.h before pkgcache.h fails because
pkgcache.h depends on cacheiterators.h.
edsp: use an ID mapping for the internal solver2016-06-04T16:45:01ZDavid Kalnischkiesdavid@kalnischkies.de2016-06-04T16:45:01Zurn:sha1:307d9eb2d13ee59191b86ffec2f36ba3fffc5c20
Currently an EDSP solver gets send basically all versions which means
the absolute count is the same, but that might not be true forever (and
with the skipping of rc-only versions it kinda is already) and even if
it were true, segfaulting on bad input seems wrong.
implement a public pkgSystem::ArchitecturesSupported2015-11-04T17:04:00ZDavid Kalnischkiesdavid@kalnischkies.de2015-09-15T12:12:19Zurn:sha1:825db89094a8413dcc9c8ef3abe0a45b0bb7a2e2implement a public pkgSystem::MultiArchSupported2015-11-04T14:02:36ZDavid Kalnischkiesdavid@kalnischkies.de2015-09-15T10:44:53Zurn:sha1:8d6d3f00b14217e69ecabd68379b1e29bf4a3ccd
Some codepaths need to check if the system (in our case usually dpkg)
supports MultiArch or not. We had copy-pasted the check so far into
these paths, but having it as a system check is better for reusability.