[Aptitude-devel] Bug#686346: dpkg is wrong about the install state of docbook-mathml, making the system in inconsistent state

[David Kalnischkies]

On Mon, Sep 3, 2012 at 9:05 PM, Guillem Jover <guillem at debian.org> wrote:
> On Mon, 2012-09-03 at 13:53:47 +0200, David Kalnischkies wrote:
>> On Fri, Aug 31, 2012 at 5:26 PM, Guillem Jover <guillem at debian.org> wrote:
>> > So it would seem to me the arch-qualifying logic in apt is not right,
>> > it really only ever needs to arch-qualify if:
>> >
>> >   * dpkg supports --assert-multi-arch
>> >   AND
>> >   * the package is Multi-Arch:same
>>
>> As I said in earlier discussions of Multi-Arch APT only checks for the first
>> and if this is true will call dpkg always with an architecture regardless of
>> if dpkg might or might not need it for this specific package simply because
>> that is a lot easier than trying to work out if this dpkg is a debian-dpkg or
>> an ubuntu-dpkg in a pre-multiarch or post-multiarch state and therefore needs
>> to spill out with architecture, without architecture or just sometimes either.
>>
>> I think you agreed with this, but my memory might trick me here.
>> I at least can't remember anyone saying that clients shouldn't - so
>> they did.
>
> That's right (that's why I said “needs”, not must :), dpkg is fine with
> clients always arch-qualifying package names, only as long as the
> architecture matches what's on the system. And as such, arch-qualifying
> a package w/o an architecture is inherently wrong. :)
>
> I guess I keep forgetting about the Ubuntu dpkg, as in: not my problem.

It's not really mine either, but fewer checks = lower chance to screw them up.
It just coincidences with not breaking other peoples toys if I can avoid it.

>> > Because M-A:same packages are guaranteed to always have a valid
>> > architecture, something that cannot be expected from non-M-A:same
>> > packages due to legacy reasons.
>>
>> Really? (I never had a package without an architecture installed …)
>
> Yeah, unfortuntately there was a time when packages didn't need to have
> an architectures field (it was not mandatory in policy), and some
> users do still have those around (!). There's also an old bug from
> dpkg, which would forget about the architecture field for some states,
> so it's actually common to find systems in those states.
>
> See #620958 for an assortment of users having those.
>
>> Anyway, dpkg does some internal defaulting, doesn't it, as otherwise
>> I don't see how such a package can satisfy any dependency on this name,
>> so it would be nice if dpkg could accept whatever default it assumes as
>> explicitly mentioned architecture, too.
>
> dpkg before multiarch has never had the architecture field into account
> in any of its dependency resolution logic, it did only verify the
> architecture of the package being installed matched the native one
> and errored out otherwise, as long as no --force-architecture was
> specified.
>
> As such treating them as native architecture packages would be risky
> and most probbly wrong (they could also be arch:all), and dpkg just
> keeps trating them as arch-less packages.

Lets reword with an example:

Package: A
Architecture: armel
Version: 2
Depends: B

Package: B
Version: 1

I would assume that A is installable, but as you say B is arch-less it can't
satisfy the dependency A has … this makes B for me a pretty useless package
especially if I upgraded A from version 1 (without an architecture).
Making B "native" or "all" (APT says it's native, but the difference isn't
that big) sounds for me like a reasonable choice. Sure, that changes if you
cross-grade dpkg, but I think you deserve some pain for ignoring warnings
from dpkg while attempting cross-grades and the alternative seems to be worse.


Best regards

David Kalnischkies