[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Making a package multiarch (for real)



On Thu, Nov 06, 2014 at 06:43:55PM +0100, Jakub Wilk wrote:
> * Mathieu Malaterre <malat@debian.org>, 2014-11-06, 18:10:
> >$ sudo apt-get upgrade
> >Reading package lists... Done
> >Building dependency tree
> >Reading state information... Done
> >You might want to run 'apt-get -f install' to correct these.
> >The following packages have unmet dependencies:
> >libcharls1:i386 : Conflicts: libcharls1 but 1.0-5 is installed
> >E: Unmet dependencies. Try using -f.
> 
> My guess is that apt tries to "upgrade" your local package to the one in the
> archive. But that won't work, because the archive version lacks  the
> Multi-Arch field.
> 
> Solution: don't reuse version numbers. :-)

That is indeed the solution, the problem is the inverse though:
apt isn't detecting that the two versions (the one online and the one in
the status file) are different as it isn't considering the Multi-Arch
field in this test [in the version you run, apt/experimental does].

So, apt is parsing the online one (without Multi-Arch and hence with the
implicit Conflicts) first and recognizes the status file stanza as a
duplicate it then records as an other source for this version.
You can observe this with "apt-cache policy $pkg".

Change something of value (Depends line for example) and apt detects it
properly. Remember though that not all tools go to all this trouble:
Many have the quite reasonable same version == same package assumption.

In other words: Go and change the version number already. ;)


Best regards

David Kalnischkies

P.S.: I say 'apt' here, but I mean 'any tool based on libapt', so you
have the same problem regardless of if you use apt-get or a software-
center. All bets are off if we talk about non-apt-based tools…

Attachment: signature.asc
Description: Digital signature


Reply to: