On Mon, Sep 3, 2012 at 9:05 PM, Guillem Jover <guil...@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 <guil...@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-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
