Hi again,
Quoting Johannes Schauer (2016-05-11 07:54:47)
> I'm cross-posting this between #823906, the dose3 upstream list and deity@,
> which should constitute all relevant parties for this problem.
my original mail seems to only have made it to bug #823906 and neither to the
apt nor dose3 list. Probably because of the attachment size. So it is here
again (quoted) for context on these two lists.
I talked with David Kalnischkies on IRC and it seems they found the reason for
this problem. More about that at the bottom of this email.
> I have seen this effect myself before but I it quickly went away after I
> updated my chroot. I now tried harder to make it reproducible for everyone.
> Here are the steps involving just a normal chroot:
>
> $ sudo debootstrap sid debian-sid-aspcud http://snapshot.debian.org/archive/debian/20160505T000000Z/
> [...]
> $ echo deb http://httpredir.debian.org/debian sid main | sudo tee debian-sid-aspcud/etc/apt/sources.list >/dev/null
> $ sudo chroot debian-sid-aspcud apt-get update
> [...]
> $ sudo chroot debian-sid-aspcud apt-get install aspcud apt-cudf
> [...]
> $ sudo chroot debian-sid-aspcud apt-get --simulate --solver aspcud -o 'APT::Solver::Strict-Pinning=false' -o 'APT::Solver::aspcud::Preferences=-removed,-changed,-new' install build-essential
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Execute external solver... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
> cpp-5 : Depends: gcc-5-base (= 5.3.1-19) but it is not going to be installed
> g++-5 : Depends: gcc-5-base (= 5.3.1-19) but it is not going to be installed
> gcc-5 : Depends: gcc-5-base (= 5.3.1-19) but it is not going to be installed
> libasan2 : Depends: gcc-5-base (= 5.3.1-19) but it is not going to be installed
> libgcc-5-dev : Depends: gcc-5-base (= 5.3.1-19) but it is not going to be installed
> libmpx0 : Depends: gcc-5-base (= 5.3.1-19) but it is not going to be installed
> libstdc++-5-dev : Depends: gcc-5-base (= 5.3.1-19) but it is not going to be installed
> E: Broken packages
> $ sudo chroot debian-sid-aspcud apt-get upgrade
> [...]
> $ sudo chroot debian-sid-aspcud apt-get --simulate --solver aspcud -o 'APT::Solver::Strict-Pinning=false' -o 'APT::Solver::aspcud::Preferences=-removed,-changed,-new' install build-essential
> [...]
> 0 upgraded, 30 newly installed, 0 to remove and 0 not upgraded.
> [...]
> Conf build-essential (12.2 Debian:unstable [amd64])
>
> So you can see how the process fails if the chroot is not up-to-date and how it
> succeeds after "apt-get upgrade" has been executed.
>
> I attached the EDSP file from the install request *before* I upgraded the
> chroot to make the installation work in the hope that 1.5 MB are not too much
> for an email attachment.
>
> Running apt-cudf on it manually yields:
>
> $ apt-cudf -v --solver=aspcud -c "-removed,-changed,-new" dump.edsp
> [...]
> Install: 10388
> Package: gcc-5-base
> Version: 5.3.1-19
> Architecture: amd64
> [...]
> Remove: 50875
> Package: gcc-5-base
> Version: 5.3.1-17
> Architecture: amd64
>
> But this seems correct as it upgrades gcc-5-base from 5.3.1-17 to 5.3.1-19 and
> I am left to wonder why apt above claims that 5.3.1-19 is not going to be
> installed. Maybe the apt people can help here?
According to David Kalnischkies, apt does not handle multiple actions for the
same package name. If it sees them anyways (like above), then it will override
earlier actions with later actions. So apt would read the above just as "remove
gcc-5-base (= 5.3.1-17)" and ignores to install gcc-5-base (= 5.3.1-19).
The package gcc-5-base is removed and installed as part of the same solution
because the EDSP format does not have an "Upgrade" action. As far as apt-cudf
or the solver is concerned the package must be removed in one of its version
and installed in another version. So from the solver's perspective having the
install and remove at the same time makes sense. From apt's perspective on the
other hand it would be sufficient to just have the "Install" request because
apt knows that it cannot co-install the same package in different versions, so
it is implicit that it will "remove" the old version.
I see three ways to fix this problem:
1. Apt should not override earlier actions by later actions but allow that a
package be removed in one version to be installed in another version as
part of the same request.
2. Apt-cudf could not generate the "Remove" action at all in situations where
there is an "Install" action for the same package, thus not confusing apt.
3. Same as (2.) but let the remaining action not be an "Install" action but an
"Upgrade" action including the old and new version in its fields.
Intuitively, I think option (1.) makes slightly more sense than the others
because the fact that an "Install" request of a higher version implicitly means
the removal of a lower version is something apt encodes. Thus this assumption
should not be made further away from apt than necessary. Additionally, it seems
natural to me, that the EDSP result contains a "removal" of the old version
because as far as many resolvers are concerned, there is per-se no problem with
installing the same package in different versions at the same time.
But I'll not be the one implementing this in apt, so these are just my 2 cents.
Thanks!
cheers, josch
Attachment:
signature.asc
Description: signature