Hi *, sorry, i had a rough end/start of the year so i am a bit late in responding…
On Mon, Jan 9, 2012 at 08:43, Guillem Jover <guil...@debian.org> wrote: > On Sat, 2011-12-24 at 06:04:46 +0100, Guillem Jover wrote: >> On Mon, 2011-12-05 at 09:55:10 +0100, Guillem Jover wrote: >> > [ pkgname I/O proposal ] > > So, any word from the frontend maintainers regarding this sub-thread? I don't see an obvious problem currently, but this might be a time thing. so lets quickly recap what happens in a dist-upgrade to be sure we are talking about the same problem set and have everything covered: apt/squeeze and dpkg/squeeze are installed and the user runs apt-get dist-upgrade: - very early in the dist-upgrade dpkg will be upgraded to wheezy => dpkg needs to accept unqualified package names for --configure even if the package was/is/will be M-A: same as dpkg is run (old and later new version) multiple times in a row - sometime later (but relatively close to dpkg) apt will upgrade the packages containing itself, library and other frontends (=friends) => these newer versions aren't used, we still work with the squeeze version and will keep doing this until the dist-upgrade is finished - maybe a package which configures dpkg to accept foreign architectures will be installed -- ubuntu did it and i don't see why other derivatives or debian itself shouldn't be at least allowed to do something similar. => the next run of dpkg will have foreign architectures configured, still, his orders are given by a process which doesn't qualify packages Before, after and in between all these three actions other packages with or without a M-A flag are installed. For most of them the M-A flag will be new, but even squeeze ships a few packages which already have a M-A flag set (but mostly foreign if i remember right). The only consistency we have in this scenario is that apt/squeeze will always talk about packages from the native architecture and that only one package with the given name will be unpacked/configured/…, so that in this scenario pkg == pkg:* == pkg:native. It's not possible to fail if the architecture isn't given, regardless of the M-A flag and this shouldn't change regardless of configured foreign architecture(s) or not. For me, after a quick check, all these seems to be satisfied. I hope i find the time to implement --assert-multiarch later the week - is there a branch with it implement for dpkg already somewhere? The plan is to just be explicit all the time in case dpkg claims at the start of the operation that it supports architecture qualifications and not relay on the interpretation of 'pkg' in dpkg in any way. It can't hurt and should be the easiest to implement… Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fbj_xhttvh43gl7dyoyjhigvpr12b737nqsynpvoud...@mail.gmail.com