Need feedback on dpkg's behaviour with multiarch packages
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.
Then ask yourself the same question but this time only libsame:i386 is
installed. Now you have:
1/ Idem to above.
2/ Assume he meant all instances of libsame, and remove libsame:i386.
3/ Even if the user has not specified the architecture for this multiarch
package, there's only arch installed, so assume it's the one that he wants
to remove.
4/ Fail because we really can't be sure what he wanted to remove.
Then ask yourself the same question but this time only libsame:amd64 is
installed. Now you have:
1/ Assume libsame == libsame:native, which is not installed, so we do
nothing.
2/ Assume he meant all instances of libsame, and remove libsame:amd64.
3/ Even if the user has not specified the architecture for this multiarch
package, there's only arch installed, so assume it's the one that he wants
to remove. Remove libsame:amd64.
4/ Fail because we really can't be sure what he wanted to remove.
Start again the analysis now considering that the users types "dpkg
--status libsame" or "dpkg --listfiles libsame". This time the output
will look like multiple packages were queried while the user gave only
one argument in the input. It has thus the potential to break scripts.
Which of the 4 interpretations above should apply in this case ?
I'll try to cover the pros/cons of the various interpretations:
* Assume foo == foo:native.
+ Simple and straightforward mapping rule.
+ Can be applied in all contexts (including dpkg --set-selections).
+ Won't break scripts.
- Requires a new syntax (foo:*) to say "all instances of this package".
- Might surprise the user with a "package not installed" error when he
wants to refer to a foreign package and he forgets to precise the
architecture name.
* Assume foo == foo:*.
+ Simple and straightforward mapping rule.
+ Matches the "Do What I Mean" logic more often.
+ Do not need a new syntax to say "all instances of this package".
- Has the potential to break scripts due to dpkg --status/--listfiles
returning multiple answers for a single argument.
- Can't be assumed in dpkg --set-selections.
* Assume foo == foo:whatever provided that whatever is unique (resolve
when there's no ambiguitiy, otherwise fail).
+ Has a feeling of "Do What I Mean" more often than not.
- Has the potential to break scripts because it will fail with
co-installable M-A packages.
- Mapping rule depends on the context of the installed system. Thus it
might mean something different on different systems.
- Requires a new syntax (foo:*) to say "all instances of this package".
- Can't be used in dpkg --set-selections.
Based on this analysis, I was leaning towards "Assume foo == foo:native"
but Guillem would prefer "Assume foo == foo:*" so we'd like some external
feedback.
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?
If we decide "assume foo == foo:*" maybe change the second rule to always
print the architecture name for a multi-arch same package, although
possibly with an alias telling that we're referring to the package of
native architecture, whatever that is (see open question below).
For reference, the various contexts in which package names are printed by
dpkg are:
- the status logs (and thus also in the file descriptor passed with --status-fd)
- output of "dpkg -l"
- output of "dpkg -S"
- output of "dpkg-query -W"
- output of "dpkg --get-selections"
- output of "dpkg --audit"
- output of "dpkg --yet-to-unpack"
- lots of messages everywhere (user messages on screen, error messages,
debug messages, etc.)
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 ?
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.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Reply to: