Re: Multiarch interfaces: print foreign arches, pkgname I/O
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 <guillem@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
Reply to: