aptcc not installing recommends #145
Comments
|
does apt install pkg to update install the recommends? |
|
It does. both upgrade and dist-upgrade as a matter of fact |
|
no, I mean install as in |
|
oh. good question. I can't check right now as I have no linux at hand until sunday, if you don't get to it before then I'll make a test repo and have a look. |
|
k thks, as aptcc should do the same as apt install foo, I only use dist-upgrade to get a list of upgradable things |
|
Testing repo: https://github.com/apachelogger/test-apt-recommends-install kitteh meows the repo also has build.sh which rebuilds the repo, update.sh which does an apt update bypassing gpg verification and test.sh which tests an install sequence apt install kitteh=1 same for dist-upgrade, same for upgrade. For good measure, I also tried qapt-batch --install kitteh (to install 2 on top of 1) which also works as expected. So there's definitely something wrong in aptcc's resolution. |
hsitter
changed the title
|
So, as it turns out this affects regular install as well. Namely if you install kitteh=2 from above's repo it won't pull in meows. I have an unfinished fix for this which is basically the same for both install and update. We first want to mark all to be changed packages without autoinst. We then want to mark all of them again but this time with autoinst. After this we probably can mark them protected, in between it's probably more of a hindrance to resolution than anything. By first marking everything without autoinst we can make sure that explicit selection trumps in an or-group e.g. I need to do a bit more testing on the when to mark things protected though. |
new arguments: autoInst and preserveAuto apt's markInstall can automatically try to resolve dependencies (incl. recommends if applicable) without having the resolver deal with broken dependencies at all. to that end it will mark dependencies of $package as auto-install which gives them a slightly lower resolution score and the auto flag (so they can be autoremoved). To facilitate its use, the interface now calls toinstall twice: once without autoInst to only mark explicitly wanted packages, and a second time with autoInst to then also mark all needed dependencies. This is specifically meant to allow or-relationships to resolve as desired. e.g. ``` Package: foobar Depends: foo|bar ``` with `pkcon install foobar bar` will explicitly mark foobar and bar and thus prevent foo from getting autoinstalled. In update scenarios it is hard to tell whether a user wants a package to be installed or updated. In particular whether or not a package is meant to be installed according to the user would prevent them from being autoremoved. A user may however run `pkcon update foo` to update foo, not because she actually thinks foo is needed or useful. To prevent unintentionally losing the auto flag on updates, the backend now always preserves the flag when updates are requested. Conversely on installs we default to not having the auto flag. fixes PackageKit#153 fixes PackageKit#151 fixes PackageKit#145
This is inconsistent with apt where both upgrade and dist-upgrade will install new recommends. Furthermore, this actually can have negative impact on any form of rolling system where this sort of thing might occur regularly.
The text was updated successfully, but these errors were encountered: