Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.1.9 2020-08-04T10:16:36Z 2020-08-04T10:16:36Z Julian Andres Klode jak@debian.org 2020-08-04T10:16:36Z urn:sha1:63c0657ea54c9268bc1855d5eac92bc636532bd6 Support marking all newly installed packages as automatically installed See merge request apt-team/apt!110 2020-08-04T10:12:30Z Julian Andres Klode jak@debian.org 2020-08-04T10:12:30Z urn:sha1:11530bab64efd4b4fc46de7833533cea9c69f521 Remove master/slave terminology See merge request apt-team/apt!124 2020-08-04T10:12:11Z Julian Andres Klode julian.klode@canonical.com 2020-07-14T14:34:20Z urn:sha1:7d8bb855487d6821b0cd6bf5d2270ed8fda3d1a3 2020-08-04T10:07:10Z Julian Andres Klode jak@debian.org 2020-08-04T10:07:10Z urn:sha1:1afe7c8b874abb61cde591e0241b967ef1b99991 Fully deprecate apt-key, schedule removal for Q2/2022 See merge request apt-team/apt!119 2020-07-02T16:57:11Z David Kalnischkies david@kalnischkies.de 2020-06-30T08:11:09Z urn:sha1:1bfc0907c987758529bcdc4ebfb34364702a2d8b It isn't needed to iterate over all results if we will be doing nothing anyhow as it isn't that common to have that debug option enabled. 2020-07-02T16:57:11Z David Kalnischkies david@kalnischkies.de 2020-06-19T16:49:11Z urn:sha1:1f910d94add8f20ebfa5999a7795e678a4af0826 We were traditionally adding points for some dependency types to the real package, but we should also do it for providers of that package to help the resolver especially if the real package is for some reason not tagged for removal yet/anymore. While at it we ensure that the points are only attributed once for each package as especially with versioned provides a package can nowadays provide another many times and would hence acquire a lot of points. 2020-07-02T16:57:11Z David Kalnischkies david@kalnischkies.de 2020-06-19T11:58:35Z urn:sha1:cfd0172fb0eeb15b2e2427c0e11b2ec65f501839 If the package providing the given solution is tagged already for removal (or at least for "not installing") we can ignore this solution as a possibility as it is not one, which means we can avoid exploring the option and potentially forward the protected flag further if that helps in reducing the possibilities to a single one. 2020-07-02T16:57:11Z David Kalnischkies david@kalnischkies.de 2020-06-19T11:14:33Z urn:sha1:3e39efa31da463ca05016513835d9a5388f80f90 Marking a package for removal is fine if we know that we have to remove that package, but if we are in an alternative branch we might not go this route in the end and hence have a package pointlessly marked for removal which isn't questioned later on. We check if we are allowed to remove that package to avoid working on the positive dependencies if not, but we mark them for removal only after all the other dependencies are successfully resolved. In an ideal world we would let the problemResolver do its job on them, but the resolver might decide against doing the removal exploring another option like the next alternative, which might be a good idea, but is not the behaviour we had before, so that is the best we can do for now without changing the resolver drastically. 2020-06-29T15:32:17Z Julian Andres Klode julian.klode@canonical.com 2020-06-29T15:31:06Z urn:sha1:ddd8fc3d28cd8e668868158049ced7fa3c8c71b8 This will be mapped to Important for the time being. 2020-06-14T08:19:39Z David Kalnischkies david@kalnischkies.de 2020-06-14T07:48:29Z urn:sha1:a1464cb4025cd737ac57ea7392402d5efd2af027 M-A:foreign causes Provides to apply to all architectures and as we wanted to avoid resolver changes for M-A those are done by explicitly creating these provides instead of forcing the resolvers to learn about this. The EDSP is a different beast though & we don't need this trick here especially as it leads to needless (but harmless) duplication. No sort+unique is done to avoid changing order (not that it should matter, but just to be sure), but the sets should be small enough to not make a huge difference either way.