Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.4.4 2022-01-06T19:56:52Z 2022-01-06T19:56:52Z Julian Andres Klode jak@debian.org 2021-12-09T10:52:12Z urn:sha1:736f13cb421604cf68f3e078e5bf0b82e0ffbc92 Avoid misclassifying additional alphabetical characters from certain locales as alpha and then sort them by ASCII... 2021-11-05T14:36:08Z Victor Westerhuis victor@westerhu.is 2021-11-05T14:36:08Z urn:sha1:8b15e3b90aa3686cecfece1361f8c7857b128e13 It looks like a debug line was left in accidentally. 2021-10-19T08:32:57Z Julian Andres Klode jak@debian.org 2021-10-19T08:32:57Z urn:sha1:bdc8526819d288f6076e1d1854138f139f2df32f apt-pkg/deb/dpkgpm.cc: make DPkg::Chroot-Directory work under fakechroot See merge request apt-team/apt!189 2021-10-18T14:12:54Z Julian Andres Klode julian.klode@canonical.com 2021-10-18T13:48:05Z urn:sha1:dcbae505308758df2870c0424e3f5a1dfebcb5ec Rename the argument to Introducer and generalize it to anything that introduces new keys into the trusted vector, like file names and full keys. 2021-10-18T14:12:54Z Julian Andres Klode julian.klode@canonical.com 2021-06-09T11:22:38Z urn:sha1:3f07f5345ec79702c3c769047452041b2c12953f Extend the Signed-By field to handle embedded public key blocks, this allows shipping self-contained .sources files, making it substantially easier to provide third party repositories. 2021-09-19T17:03:29Z Johannes Schauer Marin Rodrigues josch@mister-muffin.de 2021-09-19T17:03:29Z urn:sha1:e6f7bfb02ef254ec6922c1a3b3f9a2c741db6a79 2021-09-04T14:20:12Z David Kalnischkies david@kalnischkies.de 2021-09-04T14:10:50Z urn:sha1:70c669e2566d119559d2986635bb6c1d0d368073 APT is not the place this information should be stored at, but it is a good place to experiment and see what will be (not) needed in the future for a proper implementation higher up the stack. This is why "BarbarianArchitectures" is chosen instead of a more neutral and/or sensible "VeryForeign" and isn't readily exported in the API to other clients for this PoC as a to be drawn up standard will likely require potentially incompatible changes. Having a then outdated and slightly different implementation block a "good" name would be bad. The functionality itself mostly exists (ignoring bugs) since the introduction of MultiArch as we always had the risk of encountering packages of architectures not known to dpkg (forced onto the system, potentially before MultiArch) we had to deal with somehow and other edge cases. All this commit really does is allowing what could previously only be achieved with editing sources.list and some conf options via a single config option: -o APT::BarbarianArchitectures=foo,bar 2021-09-04T13:35:15Z David Kalnischkies david@kalnischkies.de 2021-09-04T00:22:24Z urn:sha1:79a675ddf3320bf640d130e592c86fefd1a460e1 What does a M-A:allowed package from non-native/non-foreign architecture provide? If we look at M-A:foreign, such a package satisfies dependencies within its own architecture, but not in other architectures, so the same should apply to :any dependencies on M-A:allowed packages, but we have a problem: While unqualified package names are architecture-specific, the virtual package name qualified with :any is not (see 3addaba1ff). We could of course make it architecture-specific now, but that would introduce many virtual packages for this relatively minor usecase and would reintroduce a need for special display handling. So, we pull a trick here: Barbarian M-A:allowed packages do not provide the architecture-independent :any package anymore, but only a specific one and every :any dependency from a barbarian package is rewritten to an or-group of the specific and the independent :any package. References: 3addaba1ff 2021-07-05T09:50:05Z Julian Andres Klode jak@debian.org 2021-07-05T09:50:05Z urn:sha1:544d81a26f8c97a2a45262aecbaef4a5b43fb325 Restore dpkg::chroot-directory functionality See merge request apt-team/apt!178 2021-06-10T17:25:17Z David Kalnischkies david@kalnischkies.de 2021-06-10T16:06:14Z urn:sha1:8083d4019844f764058efa2a950ed16975178bff If we call dpkg inside a chroot we have to ensure that the temporary directory we construct to call dpkg --recursive is inside the chroot and that we strip the path to the chroot from the directory name we pass to dpkg. Note that the added test succeeds before and (hopefully) after as we can't really chroot here or fiddle with the needed settings as we are already setting up apt to work with a quasi-chroot. The test perhaps helps in ensuring we don't break it too much in the future though. (Broken five years (and one day) ago this seems to have an immense user base at the moment, but it might in the future via mmdebstrap) References: f495992428a396e0f98886c9a761a804aa161c68 Reported-By: Johannes Schauer Marin Rodrigues on IRC Tested-By: Johannes Schauer Marin Rodrigues