Re: Need feedback on dpkg's behaviour with multiarch packages
Raphael Hertzog <hertzog@debian.org> writes:
> Hi,
>
> with Guillem we're wondering how we should "interpret" an unqualified
> "foo" when foo is a multi-arch package. For the sake of the example,
> we'll use "libsame" a package which is Multi-Arch: same (and thus
> coinstallable) and "pkg-foreign" a package which is Multi-Arch:
> foreign/allowed (and we assume we actually have installed a foreign
> instance on this package on our system).
>
> How to interpret the input
> --------------------------
>
> Consider that we have installed libsame:i386 and libsame:amd64 on the
> system (which is an i386 system).
>
> The user types "dpkg -r libsame". What do you expect dpkg to do?
>
> 1/ Assume libsame == libsame:native and remove libsame:i386 only.
> 2/ Assume he meant all instances of libsame, and remove libsame:i386 and
> libsame:amd64.
> 3/ Fail because the user has not been specific enough.
I think the behaviour should be to match how you print package names. So
lets skip to that.
> How to print the package names
> ------------------------------
>
> In the same vein, we should decide how dpkg is going to print package
> names in various contexts. Obviously the decision above will have an
> impact here... because scripts might retrieve package names from
> the output of dpkg and feed it back in the input of other dpkg commands.
>
> My suggestion is along those lines:
> - any package of foreign arch should always have its architecture appended
> to its package name
> - package of native arch which are multi-arch same should have the
> architecture appended only if there are other instances of the same
> package installed
> - other packages do not need the arch qualifier
>
> Does that seem reasonable enough?
Lets first consider an existing systems. The output of packages is
without the architecture. In the future many systems will still have
just one architecture installed despite having multiarch packages
available. The conservative approach is to sill not add the architecture
to the output.
On the other hand for multiarch systems there must be a way to
differentiate the library packages from different architectures. There
can be many architectures but only one native one. Since we can only
allow one architecture to not add the architecture to the name and still
be unique the foreign archs must add the architecture.
If we show native packages without the architecture added at all times
then the output is the same for old systems, new systems with only
native packages and new systems with foreign packages. Installing
libfoo:amd64 does not change that libfoo means libfoo:i386 and that
libfoo:i386 is displayed as libfoo. I think that is the most consistent
way. Having the name change depending on what else is installed would be
confusing.
As a special case I would allow foo to match foo:amd64 if foo is not
multi-arch same package for the purpose of specifying packages but still
display the architecture on output.
> One more question:
> - shall we invent a "foo:native" syntax that we can output instead of
> "foo:i386" in the output of dpkg --get-selections so that transferring
> the selection over to another computer running another architecture
> will still work ?
Using plain "foo" avoids this issue and keeps things compatible between
old and new systems. You can then transfere your selections from squeeze
to wheezy and back.
> I have included deity@lists.debian.org because APT developers have
> certainly taken some decision on this topic when they have implemented
> multi-arch support in APT. Dear APT developers, your input as frontend
> developer is very welcome on those topics.
MfG
Goswin
Reply to: