[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#673193: apt-get: should remove foreign arch packages even if arch suffix is missing



On Wed, May 16, 2012 at 10:16 PM, Carsten Hey <carsten@debian.org> wrote:
> apt-get should remove foreign arch packages even if arch suffix is
> missing.
>
> I know that you disagree, but documenting unintuitive behaviour in the
> BTS in a good thing and this bug report explains why your reasoning is
> wrong.

In that sentence "you(r)" is /me, just so that everyone gets who is meant.

/me is the one implementing MultiArch in APT with its own mindset in 2010
as a GSoC project for debian after starting talking about it in 2009 after
it was said that dpkg could have MultiArch enabled in 2 weeks.


I never really asked others to agree with me, so you might actually find
apt maintainers (depending on who you define as such, i am e.g. not one)
who happens to agree with you. If you find such a someone who is willing
to change it in time for wheezy (i think it is unreasonable to change it
after wheezy release, but maintainer choice…) then by all means: Go for it.


>  # dpkg --print-architecture
>  amd64
>  # dpkg -l sc | grep ' sc' | tr -s ' '
>  ii sc 7.16-3 Text-based spreadsheet with VI-like keybindings
>  # apt-get remove sc
>  ...
>  Package 'sc' is not installed, so not removed. Did you mean 'sc:i386'?
>  0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>  # dpkg -s sc | grep Arch
>  Architecture: i386
>
> Actually there are two bugs shown above.  One is that dpkg -l omits
> important information.

No, dpkg is consistent in it's out-/input as is apt, so no bug.
The out-/input just happens to be inconsistent between apt and dpkg.

I could invoke the "i was first" argument here, but the "better" argument
is that dpkg only needs to specify an architecture if a M-A:same package
is involved (and in that case it forces it) while apt has to deal with all
packages being either native or foreign at all times, so if multiple
architectures for a package are available it needs to know which one
the user talks about. For convenience native is assumed by default for
all packages -- i am just not enough of a man to require everyone to
always specify an architecture.


> The other is that apt-get only removes foreign packages if either the
> arch suffix is added or if the package is not available on the native
> architecture.  The reasoning by apt's maintainers is that in the above
> case sc:i386 must explicitly have been installed, which is obviously
> wrong since that a packages is available on one architecture now does
> not mean that it has been available on this architecture in the past and
> apt installs foreign packages if the architecture suffix is not added
> and the package does not exist on the native architecture.

Again, it's just me with that reasoning with nobody publicly disagreeing
with me so far who ended up changing it cause of that, but this doesn't
make it a plural nor me an apt maintainer.
(Just keeping facts straight)

The logic consequence of this "bug" is through to remove the convenience
of installing the foreign package in case no native package is available,
not to add even more "maybe the user meant something else" logic…
It's up to frontends to guess what the user meant, apt-* usually does what
the user said, even through the user might be wrong. I personally think that
is better than trying to tell the program that i am not the idiot the program
thinks i am and therefore decides to do something else instead.
At least for a tools as low-level as apt-*.


Not sure if this is really a usability improvement. Properly as useful as
removing the native is default assumption. I am doing neither but maybe
someone else… for me the multiarch topic is done simple because i don't
have the energy to discuss the same thing for more than two years.
I really don't know how Steve, Goswin and co could do this -
and even far longer… (yes, i know, the obvious reason is: i am too weak)


Best regards

David Kalnischkies

P.S.: Yeap, this no maintainer thing is by choice and i like it.
And others should like it, too, as their is no need for a ctte…
Just go and write patches, you don't have to care about me,
i know how to compile my own apt if everything else fails.



Reply to: