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

[Vincent Lefevre]

On 2012-09-03 21:05:06 +0200, Guillem Jover wrote:
> 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. ]

The clone still isn't in the BTS while there are more recent bugs
than 2012-09-03 21:05:06 +0200. Did the command succeed?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel

Re: [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  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  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

___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel

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

[Guillem Jover]

Control: clone 686346 -2
Control: reassign -2 aptitude
Control: retitle -1 apt: Should not arch-qualify arch-less packages on dpkg 
calls
Control: retitle -2 aptitude: Should not arch-qualfy arch-less packages on dpkg 
calls

On Tue, 2012-09-04 at 01:41:36 +0200, Vincent Lefevre wrote:
> On 2012-09-03 21:05:06 +0200, Guillem Jover wrote:
> > 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. ]
> 
> The clone still isn't in the BTS while there are more recent bugs
> than 2012-09-03 21:05:06 +0200. Did the command succeed?

Oh, right, it didn't succeed because the command was wrong. Hopefully
fixed now.

thanks,
guillem

___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel

Re: [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  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

___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel