David Kalnischkies wrote:
> Why would it be intuitive to add a specific value for the arch attribute with
> apt-get install foo # arch |= native
> but remove all values of the attribute with
> apt-get remove foo # arch &= ~all-architectures
> ?
>
> Isn't it more intuitive to have it this way:
> apt-get remove foo # arch &= ~native
> ?
>
> Maybe we just have different definitions of intuitive.
Intuitions vary from person to person; that's definitely not news.
But I really think this is something anyone can get used to. In the
examples you listed above:
apt-get install foo; # install foo with default arch-list (native)
apt-get remove foo; # remove foo
If foo is installed for no architectures, that does not mean it is
installed with an empty architecture list. It means it is simply not
installed.
In practice, that would match what I want to do, too.
* There is a web browser I would like to use. I don't care which
arch --- that's an implementation detail.
apt-get install iceweasel
* Oops, never mind --- not interested in using that web browser any
more.
apt-get --purge remove iceweasel
* I've never heard of this multiarch stuff, but the unpackaged
software I am trying to install is giving complaints about missing
libfoo.so.1
apt-get install libfoo1
* Ok, now I've learned about multiarch, and I want to install libfoo
to satisfy a dependency for a binary on a foreign architecture.
apt-get install libfoo1:amd64
* I don't want libfoo any more --- remove it completely from the
system.
apt-get --purge remove libfoo1
"Wait!" you might protest. "Isn't that last command too aggressive?"
After all, I did not specify which architecture motivated the removal
of libfoo1. Maybe I was removing libfoo1 for the sake of my
unpackaged i386 software but I still need it for unpackaged amd64
software, and apt could help me out by picking the architecture I
intended and not removing it elsewhere, right?
But no, that would not be helpful at all. It's true that libfoo1
might be installed for more than one reason and I might have forgotten
about some and therefore remove it when that is not warranted, but
that's true whether multiarch is involved or not. This safety feature
does not add any real consistent safety.
I can think of only one advantage to making "apt-get remove libfoo1"
remove libfoo1:native, though it's a good one. That's to support
muscle memory and scripts that rely on the "libfoo1 always means
libfoo1:native" semantics that have been present in Ubuntu for a
little while. I think it's worth losing that, since as we've seen,
most scripts dealing with cases like this are going to need changes to
work with "multiarch: same" packages anyway (and humans can grow to
appreciate the simple mental model Russ suggested).
Jonathan
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120217165937.GA9360@burratino
