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

[Guillem Jover]

Control: clone -1 aptitude

[ CCing aptitude due to the clone, please see the bug report for more
  details, also about it probably deserving to be serious. ]

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.

> > 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.

> Otherwise we need to clone this to aptitude (as it does some direct dpkg
> calling on its own as far as I know) and whatever other dpkg front-end assumed
> that it could arch-qualify everything in a multi-arch universe.

Ok, cloned now, thanks.

regards,
guillem