There are different schools on multilib behaviour. One is to have
minimal installs, e.g. do not install all arch versions just because
they exits, the other is to do so, as asking a package manager for
package foo is ambiguous (all of them or just the native package?).
FWIW, the currently adopted approach in Smart is to have disjoint graphs
on multilib packages. In other words, if there are 64bit and 32bit
versions of a package, they'll be upgraded by newer versions of their
counterparts.
Sometimes I'm setting up multilib-free systems (e.g. no
overlapping
packages at all), and a yum install foo (w/o adding an arch) will pull
in both x86_64 and i386 packages.
So it is basically more a matter of personal taste than consensus. I
That's what I see as well.
would suggest the following:
o make an explicit removal w/o any arch mean "remove for all archs". I
think that is unambigous.
What if the user wanted to remove just the 32bit version?
o make the explicit install of a package w/o mentioning any arch be
dependent on configuration, so some users can have "all archs" and
some "only the best arch"
o make the updating/fixing algorithm be generally minimal in package
installations, or perhaps depend on the above configuration
setting.
Thanks a lot for these suggestions. I'll write them down and study
if what Smart currently implements could be enhanced by implementing
something around your ideas.
In general I think less is better ;)
I agree. The real issue about this is creating some scheme that users
actually expect, making usual things simple, and unusual things
possible. I hope to put my hands on a multilib system ASAP, to be able
to also develop my own feeling about these cases.
Thank you very much!
--
Gustavo Niemeyer
http://niemeyer.net