Re: Multiarch interfaces: print foreign arches, pkgname I/O
On Thu, Dec 15, 2011 at 02:02, Guillem Jover <guillem@debian.org> wrote:
> Even then, as I stated on my initial mail, if we ignore the
> cross-grade case, let's consider the situation of a system with just a
> i386 essential package set, where an amd64 apt (and needed dependencies)
> have just been installed. The notion of native arch is going to be
> different for both dpkg and apt which depending on the interface might
> produce interesting results to say the least.
Where should be nothing (serious) preventing APT to be always
explicit about which package it wants to be worked on by dpkg,
so that the native understanding of dpkg isn't all that important for
apt/future, i am just concerned about the usage of dpkg/multiarch with
apt/squeeze which happens in the squeeze->wheezy update and about manual
usage which happens all to often in script/oneliners to e.g. remove
obsolete packages.
Common is e.g. to ask deborphan for a list of packages and let dpkg
purge them, which could cause quiet a bit of havoc in case of a
some-arch-needed-other-arch-not-needed package in the output.
> In addition all this is for M-A: same packages, which should in most
> (if not all?) cases be just dependency packages, not something the
> user might need to request by hand, and as such if they'd need to,
> they can use the proper syntax.
-dev and -dbg packages could be M-A: same and are (more) likely
installed by hand. Plugins could be, in general everything which doesn't
need to be unique in some way. In some far away future we might be
able to even co-install binaries. Also, there are libraries out there which
are not tagged as M-A: same and some will change their state over time,
so that we have M-A: none installed and M-A: same available online
and need to decide which one will be used to decide how the interface
should react… this soon becomes unpredictable for users.
Beside, that interpreting no-architecture as native-architecture is the
option of least breakage as this was what it was previously - just that
nobody had the option to request another architecture before.
So if user/script/application-expectations aren't completely
broken, they should keep working in and outside of multiarch…
>> The idea of not printing the architecture for M-A:foreign packages is also
>> a dpkg-vs-apt thing as APT needs to provide the user with a way to choose
>> which architecture should it be and if it changes the architecture it has to
>> display this somehow and showing 'removing libc-bin; installing libc-bin'
>> isn't exactly useful to understand what actually happens.
>
> Well, I'd argue that's a flaw in the current implementation then, the
> need for removal and reinstallation is arbitrary and not something that
> should be really required, dpkg has supported until now cross-grading a
> package to a different architecture even if it stopped doing so in some
> cases now on the multiarch branch, and as you pointed out already
> something that will definitely cause problems with essential or
> pseudo-essential packages.
Yeah by applying the needed --force everything is possible… ;)
As i said, the implementation just acts according to the conflicts - and
is this way very simple. If we find later some more clever way to avoid
the need to explicitly remove the other architecture, fine. We can change
APT then, until then it will just work this way in most cases and cries
loudly in the essential-case. I just think that we don't need to delay
M-A for this essential-crossgrade as it is more or less an add-on.
Best regards
David Kalnischkies
Reply to: