Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.3.10 2021-10-18T13:36:00Z 2021-10-18T13:36:00Z Julian Andres Klode jak@debian.org 2021-10-18T13:36:00Z urn:sha1:edf4b2169405e7ca6e21f408229e5fc4bbd4f4ed Streamline access to barbarian architecture functionality See merge request apt-team/apt!184 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-08-16T22:04:14Z urn:sha1:017b3d0ae5232628c15324204e607e76487afb99 Back than M-A was added to build-dependencies (#558104) only the qualifiers :native and :any were considered at first which for the native case behave the same, so stripping was a good idea. Nowadays we could encounter arch-qualified dependencies, too, through – or slightly more likely conflicts perhaps – at least in theory as in practice native build-dep operations in Debian and elsewhere wouldn't have other architectures available anyhow. Still, we have full support for all this for the crossbuilding case which makes active use of this (at least is far more likely to do so), so it seems better to converge on one edgecase rather than keeping two in active use and so produce potentially different results for not specifying -a and -a $native. 2021-08-28T20:21:35Z David Kalnischkies david@kalnischkies.de 2021-08-28T16:08:15Z urn:sha1:e267d1ee54e3e2a9478201192293f3f8c72e118c As we never display the information in these code paths there isn't a lot of point in calculating it first saving us some precious CPU cycles. References: d6f3458badf2cfea3ca7de7632ae31daff5742be 2021-08-09T20:24:43Z Julian Andres Klode julian.klode@canonical.com 2021-08-09T20:15:58Z urn:sha1:2f510c5632ba83b97c6eb86ebf5e39085fde74fe Comparison operators need to be const-invocable now, but otherwise no change seems necessary. 2021-07-01T09:34:04Z Julian Andres Klode julian.klode@canonical.com 2021-07-01T09:34:04Z urn:sha1:690f6191a4332123a912c812a19a37cef253e90c We just used the pointer returned which might be nullptr, properly call BuildSourceList() and check the result first. Closes: #990518 2021-06-04T14:45:02Z David Kalnischkies david@kalnischkies.de 2021-06-04T12:15:46Z urn:sha1:ba18c4323ecbc66e6a1e3fedae60721f9c5701b1 If a source is not copying files to the destination the download code forces the copy – which in practice are local repositories accessed via file:/ – but in that process takes the filename the local repo used rather than the filename it e.g. advertised via --print-uris. A local repository could hence override a file in the current directory if you use 'apt download', which is a rather weak ability, but still. 2021-04-29T08:42:59Z Julian Andres Klode julian.klode@canonical.com 2021-04-29T08:42:59Z urn:sha1:b60cda7992d316123b036a4a0eb5f472d21e9cdd This reverts commit 64127478630b676838735b509fec5cdfa36874c8. 2021-04-29T08:28:08Z Julian Andres Klode jak@debian.org 2021-04-29T08:28:08Z urn:sha1:a6cb741a2cd1fa132705f8f5644872fc9708fb68 Count uninstallable packages in "not upgraded" See merge request apt-team/apt!169 2021-04-26T11:00:24Z David Kalnischkies david@kalnischkies.de 2021-03-18T16:37:49Z urn:sha1:d6f3458badf2cfea3ca7de7632ae31daff5742be An interactive tool like aptitude needs these flags current far more often than we do as a user can see them in apt only in one very well defined place – the autoremove display block – so we don't need to run it up to four times while a normal "apt install" is processed as that is just busywork. The effect on runtime is minimal, as a single run doesn't take too long anyhow, but it cuts down tremendously on debug output at the expense of requiring some manual handholding. This is opt-in so that aptitude doesn't need to change nor do we need to change our own tools like "apt list" where it is working correctly as intended. A special flag and co is needed as we want to prevent the ActionGroup inside pkgDepCache::Init to be inhibited already so we need to insert ourselves while the DepCache is still in the process of being built. This is also the reason why the debug output in some tests changed to all unmarked, but that is fine as the marking could have been already obsoleted by the actions taken, just inhibited by a proper action group.