Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=3.1.11 2022-09-02T21:37:58Z 2022-09-02T21:37:58Z David Kalnischkies david@kalnischkies.de 2022-09-02T09:07:58Z urn:sha1:e1f332324f81b589561a9d9bce8a55d4895f26ec The command line is evaluated in two steps: First all packages given are marked for install and as a second step the resolver is started on all of them in turn to get their dependencies installed. This is done so a user can provide a non-default choice on the command line and have it respected regardless of where on the command line it appears. On the other hand, the order in which dependencies are resolved can matter, so instead of using a "random" order, we now do this in the order given on the command line, so if you e.g. have a meta package pulling in non-default choices and mention it first the choices are respected predictably instead of depending on first appearance of the package name while creating the binary cache. I might have "broken" this more than a decade ago while introducing the reworked command line parsing for Multi-Arch, which also brought in the split into the two steps mentioned above which was the far more impactful 'respect user choice' change. This one should hardly matter in practice, but as the tests show, order can have surprising side effects. 2021-11-27T10:22:38Z Ville Skyttä ville.skytta@iki.fi 2021-11-03T22:08:07Z urn:sha1:01eed4234440d82fc52c8186cf4268517bcd28bc 2021-04-25T14:25:57Z David Kalnischkies david@kalnischkies.de 2021-03-06T13:12:01Z urn:sha1:f90b892e6acc0ca725811ef0dd9be3fed66c444f If a first step of the solver can figure out that a package is uninstallable it might reset the candidate so that later steps are prevented from exploring this dead end. While that helps the resolver it can confuse the display of the found solution as this will include an incorrect count of packages not upgraded in this solution. It was possible before, but happens a fair bit more with the April/May resolver changes last year so finally doing proper counting is a good idea. Sadly this is a bit harder than just getting the number first and than subtracting the packages we upgraded from it as the user can influence candidates via the command line and a package which could be upgraded, but is removed instead shouldn't count as not upgraded as we clearly did something with it. So we keep a list of packages instead of a number which also help in the upgrade cmds as those want to show the list. Closes: #981535 2021-04-23T10:26:46Z Julian Andres Klode julian.klode@canonical.com 2021-04-23T08:36:18Z urn:sha1:dc11a4422d99cb49817c827b9f827617b5880600 This enables hooks to output additional information. 2018-05-11T15:58:46Z David Kalnischkies david@kalnischkies.de 2018-04-12T07:59:47Z urn:sha1:6085ab7488326cfed8f82e07eefcbc2dc40d4bea Now that --with-source is supported in show we can go a little further and add the "syntactic sugar" of supporting deb-files on the commandline directly to give users an alternative to remembering dpkg -I for deb files & as a bonus apt also works on changes files. Most of the code churn is actually to deal with cases probably not too common in reality like mixing packages and deb-files on the commandline and getting the right order for these multiple records. Closes: 883206 2018-05-11T15:58:46Z David Kalnischkies david@kalnischkies.de 2018-01-26T22:33:25Z urn:sha1:ce9223cc4e4ffcc43d17ae97ff8c57fb759a2c49 The syntax is a bit awkward, but it is the same as for a package name and introducing another syntax wouldn't really help usability, so with apt install ./foo.deb/experimental you will get the dependencies of foo satisfied by your default release, but if this wouldn't satisfy the version requirements the candidate for this dependency is switched to the version from the experimental release. The same applies for apt build-dep ./foo.dsc/stable-backports which was the initial request. 2018-04-15T19:11:42Z Julian Andres Klode julian.klode@canonical.com 2018-04-13T10:32:35Z urn:sha1:e9796b9c21ee7d8e8f5d6e2a24db43fc4368b557 This allows third-party package managers like snap or flatpak to hook in and suggest alternatives if packages could not be found, for example. This is still highly experimental and the protocol might change in future versions. 2017-07-12T11:57:51Z Julian Andres Klode jak@debian.org 2017-07-12T11:40:41Z urn:sha1:87274d0f22e1dfd99b2e5200e2fe75c1b804eac3 This makes it easier to see which headers includes what. The changes were done by running git grep -l '#\s*include' \ | grep -E '.(cc|h)$' \ | xargs sed -i -E 's/(^\s*)#(\s*)include/\1#\2 include/' To modify all include lines by adding a space, and then running ./git-clang-format.sh. 2017-07-12T11:56:05Z Julian Andres Klode jak@debian.org 2017-07-12T11:42:18Z urn:sha1:c46f94aa48a9707668c46118b3eec77ff318b78c Including cacheiterators.h before pkgcache.h fails because pkgcache.h depends on cacheiterators.h. 2016-07-22T14:05:09Z David Kalnischkies david@kalnischkies.de 2016-07-08T13:59:23Z urn:sha1:92296fe4b0862a04ea3d965b4cd2d4a420e3be9f We support installing ./foo.deb (and ./foo.dsc for source) for a while now, but it can be a bit clunky to work with those directly if you e.g. build packages locally in a 'central' build-area. The changes files also include hashsums and can be signed, so this can also be considered an enhancement in terms of security as a user "just" has to verify the signature on the changes file then rather than checking all deb files individually in these manual installation procedures.