--- Begin Message ---
Package: apt
This problem was discovered because of the following situation. An Ubuntu user had added a ppa with a backported lib in it. He then installed the lib. He later added another ppa, unrelated to the first, which also had the same lib, backported, with the same version string. He tried to install the muliarch version of the lib, and apt selected the second ppa for that. But the changelogs were different. Apt refused to overwrite the changelog from ppa 1 with the changelog from ppa 2. The user's system was then left in a broken state with -f install not being able to fix it. I discovered that apt chooses the preferred repository when all else is equal using essentially whichever entry appears first in the alphabet. Obviously I think this can improve. Apt could ask the user for a decision on which repo to use, or could simply use the repo the original lib was taken from to avoid this kind of essentially meaningless conflict in the future, or offer the user an easier way out of it (all of this happened because of a few differences in the changelog, hardly important enough reason to break a system).
Here's the user's apt-cache policy for that package:
Here's how the result left his system:
--- End Message ---
--- Begin Message ---
Hi Brandon,
On Wed, Sep 18, 2013 at 11:17 PM, Brandon Snider
<brandonsnider@ubuntu.com> wrote:
> This problem was discovered because of the following situation. An Ubuntu
> user had added a ppa with a backported lib in it. He then installed the lib.
> He later added another ppa, unrelated to the first, which also had the same
> lib, backported, with the same version string. He tried to install the
That is the actual problem.
The two PPAs should NOT have the same version as they don't provide the
same version. They might have compiled the same upstream release, but
they might have packaged it differently (patches, metadata, …).
That the changelog is different is later the proof that the metadata differs.
The correct way to do it is to provide a third PPA which provides only the
library and is a "dependency" of the other PPAs. This way you can 'ensure'
that the libraries are the same and work for both – otherwise they are just
to different packages which have the same name and might (or might not)
work if they are exchanged. Still means that the version number indicates
that this is coming from a PPA of course…
(I think I heard that launchpad allows dependency to be express,
but I tend to run away screaming then I hear PPA …).
> muliarch version of the lib, and apt selected the second ppa for that. But
> the changelogs were different. Apt refused to overwrite the changelog from
> ppa 1 with the changelog from ppa 2. The user's system was then left in a
> broken state with -f install not being able to fix it. I discovered that apt
> chooses the preferred repository when all else is equal using essentially
> whichever entry appears first in the alphabet. Obviously I think this can
> improve.
This isn't obvious because this behavior is documented in sources.list which
also mentions the biggest usecase for it: preferring CD-ROM/local mirrors
over slower sources …
> Apt could ask the user for a decision on which repo to use, or
> could simply use the repo the original lib was taken from to avoid this kind
> of essentially meaningless conflict in the future, or offer the user an
… so we can't just change that. And especially don't bug millions of users
just because some PPAs don't play nice in the established ecosystem.
The problem with taken e.g. pkg:i386 from the source we got pkg:amd64 is
that we don't know where pkg:amd64 came from at that time anymore –
and even if we would know its full of loop holes: We could have installed
it from 'unstable' a week ago, so now the version we should get is the one
from 'testing' as 'unstable' carries another version. We could have it
installed from my local mirror which lacks behind a few days and so hasn't
got the i386 package and apt should just get it from the far away mirror.
Or my local mirror has no i386 packages to begin with as a partial mirror …
Way to many cases to consider – and the initial problem still stands:
The different packages should not have the same version because they
are not the same version.
> easier way out of it (all of this happened because of a few differences in
> the changelog, hardly important enough reason to break a system).
This has nothing to do with APT, that is dpkg, but is the same problem
and solved in the same way.
So, as this isn't a bug in APT but in the PPAs I am closing this bugreport.
Best regards
David Kalnischkies
--- End Message ---