FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian dpkg

 
 
LinkBack Thread Tools
 
Old 09-03-2012, 11:53 AM
David Kalnischkies
 
Default Bug#686346: dpkg is wrong about the install state of docbook-mathml, making the system in inconsistent state

(cc'ing debian-dpkg@ as this possibly is a problem for any dpkg user)

On Fri, Aug 31, 2012 at 5:26 PM, Guillem Jover <guillem@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.


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

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.


Best regards

David Kalnischkies


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAAZ6_fCxFK1vyPr7fHqy7pVGAE6bYZ3zav1DTgzUuiwsvzePe A@mail.gmail.com">http://lists.debian.org/CAAZ6_fCxFK1vyPr7fHqy7pVGAE6bYZ3zav1DTgzUuiwsvzePe A@mail.gmail.com
 
Old 09-03-2012, 07:05 PM
Guillem Jover
 
Default Bug#686346: dpkg is wrong about the install state of docbook-mathml, making the system in inconsistent state

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


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120903190506.GA9741@gaara.hadrons.org">http://lists.debian.org/20120903190506.GA9741@gaara.hadrons.org
 
Old 09-03-2012, 08:12 PM
David Kalnischkies
 
Default Bug#686346: dpkg is wrong about the install state of docbook-mathml, making the system in inconsistent state

On Mon, Sep 3, 2012 at 9:05 PM, Guillem Jover <guillem@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@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


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAAZ6_fD_90vHStCAH0Rw5cayYHoG3RLV_jpmf-mgAmr95gQzHQ@mail.gmail.com">http://lists.debian.org/CAAZ6_fD_90vHStCAH0Rw5cayYHoG3RLV_jpmf-mgAmr95gQzHQ@mail.gmail.com
 
Old 09-03-2012, 11:41 PM
Vincent Lefevre
 
Default Bug#686346: dpkg is wrong about the install state of docbook-mathml, making the system in inconsistent state

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 Lefvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120903234136.GA5600@xvii.vinc17.org">http://lists.debian.org/20120903234136.GA5600@xvii.vinc17.org
 
Old 09-04-2012, 12:54 AM
Guillem Jover
 
Default Bug#686346: dpkg is wrong about the install state of docbook-mathml, making the system in inconsistent state

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


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120904005433.GA13655@gaara.hadrons.org">http://lists.debian.org/20120904005433.GA13655@gaara.hadrons.org
 
Old 09-04-2012, 01:52 AM
Daniel Hartwig
 
Default Bug#686346: dpkg is wrong about the install state of docbook-mathml, making the system in inconsistent state

On 3 September 2012 19:53, David Kalnischkies
<kalnischkies+debian@gmail.com> wrote:
> 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.

David, any chance of getting the final, “correct” logic some place
libapt consumers can access?

static string pkgDPkgPM::GetDPkgName(VerIterator const &);

In aptitude we use this once to call dpkg-reconfigure. Is there a way
to do this with ::Go that I am not aware of? Also, “dpkg --configure
-a”?


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CAN3veRfbQ=GiSxrMZ0phdJxxPNpv6fCL=nM-pSoc+3GvP7s50g@mail.gmail.com
 

Thread Tools




All times are GMT. The time now is 04:34 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org