Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.4.1 2022-02-10T17:35:53Z 2022-02-10T17:35:53Z David Kalnischkies david@kalnischkies.de 2022-02-08T14:39:45Z urn:sha1:24d4cf6216ded26e6a6517a46c6f9115275b7136 Our EDSP code is confused by the spaces in the package name, so we adopt a naming scheme similar to build-dep here instead of trying to teach EDSP to somehow encode the spaces as that is probably even more confusing for onlookers than this invalid package name is. Reported-By: Johannes Schauer Marin Rodrigues on IRC 2022-01-21T14:14:00Z Julian Andres Klode jak@debian.org 2022-01-21T14:11:56Z urn:sha1:78981cd5ec19563cf3bca2495c56e31124ae069a This adds back the missing fields that we do not show any other way. 2021-11-27T10:22:38Z Ville Skyttä ville.skytta@iki.fi 2021-11-03T22:08:07Z urn:sha1:01eed4234440d82fc52c8186cf4268517bcd28bc 2021-11-23T13:18:25Z David Kalnischkies david@kalnischkies.de 2021-11-09T19:37:18Z urn:sha1:dd81b736095f244454c7f179e67f21c08f3fbce9 The Debian 11 release notes elevate matching with regex to a documented and much used feature, which it previously wasn't. For binary packages this is not a problem, but source packages are special and it turns out that matching by release is here an exact string match only. A bit of refactoring later we can reuse the code we use for Packages files also for Release files, which is what we have for Sources files as those files itself have no representation in the cache. This means that we do not support matching based on components (c=main) in source, but we didn't before and we can cross that bridge if anyone notices… Closes: #998444 2021-11-17T16:21:03Z Julian Andres Klode julian.klode@canonical.com 2021-11-17T16:20:29Z urn:sha1:21cc694f55de7caede8dcef3831236b6ca855cd7 Let's make this one step harder. 2021-10-19T15:02:17Z Julian Andres Klode jak@debian.org 2021-10-19T15:02:17Z urn:sha1:9d9ccbbc685035e410e9f3dd5dd488a21d48661d Allow =version and /release selectors on virtual packages See merge request apt-team/apt!121 2021-10-19T13:38:22Z Julian Andres Klode julian.klode@canonical.com 2021-10-19T13:31:22Z urn:sha1:400a6895566b67d70bcde43dc8a1cc1c7121f87d When color has not been turned on explictly in the configuration file or options, only turn it on if NO_COLOR is not set. 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.