aptcc not installing recommends

[apachelogger]

• foobar 1.0 doesn't recommend kitteh
• foobar 2.0 recommends kitteh
• pkcon update from 1.0 to 2.0 doesn't want to install kitteh

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.

[dantti]

does apt install pkg to update install the recommends?

[apachelogger]

It does. both upgrade and dist-upgrade as a matter of fact

[dantti]

no, I mean install as in
apt install foo
upgrade and dist-upgrade are different

[apachelogger]

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.

[dantti]

k thks, as aptcc should do the same as apt install foo, I only use dist-upgrade to get a list of upgradable things

[apachelogger]

Testing repo: https://github.com/apachelogger/test-apt-recommends-install

kitteh
version 1 = no relationships
version 2 = recommends on meows

meows
version 1 = recommended on by kitteh

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
apt install kitteh
leads to:

The following NEW packages will be installed:                                                                                                
  meows   

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.

[apachelogger]

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. Depends: foo | bar with pkcon install meow bar will definitely pick bar rather than foo where autoinst would pick foo.

I need to do a bit more testing on the when to mark things protected though.