Re: Need feedback on dpkg's behaviour with multiarch packages
On Mon, Jan 31, 2011 at 11:56, Raphael Hertzog <hertzog@debian.org> wrote:
> 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.
I fear i am of no help in this regard as APT has superior knowledge:
APT::Architectures defines which Architecture data should be downloaded
and in which order giving Architectures a preference, so the current
implementation simply assumes if no specific architecture is requested
that the most preferred Architecture is meant (currently its completely
dependent on the order of this list, but i kind of like the idea to look first
at the pinning values to have a finer control).
This was chosen simple because most people will not care which
architecture the package they want to install is built for.
They simply want the program inside installed, regardless of arch
and version (otherwise they had been more specific).
The remove follows for consistence the same rules which leads to
interesting cases like a failing 'apt-get remove foo' on an amd64 machine
with i386 and amd64 available but i386 installed as APT assumes
that foo:amd64 was meant -- but the install request in this situation
was 'apt-get install foo:i386' so its at least consistent in its small world.
If we would go for a 'what the user meant was foo:installed-arch' we
would need to choose for 'same' libraries or removing both which is
kind of awkward if your install request was 'apt-get install libsame'
5 minutes ago and now you need to get right of the package with
'apt-get remove libsame:amd64' because libsame:i386 is installed
for ages now on your computer because of foo:i386.
So, all in all, i would vote for no arch = native - simply because you have
similar problems not only for remove and purge but for example also
on --configure libsame after an unpack request for :i386 and :amd64
was done. Which one do you want to configure now:
- both (in which order?)
- the native one (:amd64)
- fail as not specific enough
Does this change if the :amd64 one is already configured?
- (assume :amd64 as :native) fail as already configured
- choose :i386 (as :amd64 as native is already) and configure it
- choose both, ignore :amd64 and configure :i386
- choose both, fail :amd64 as already configured (and maybe configure i386)
- fail as not specific enough
Best regards
David Kalnischkies
Reply to: