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

Re: Dependencies a little excessive?



On Thu, 2006-08-10 at 22:34 -0400, seth vidal wrote:
> On Thu, 2006-08-10 at 15:33 -0700, Toshio Kuratomi wrote:
> > On Thu, 2006-08-10 at 15:04 -0400, seth vidal wrote:
> > 
> > > okay - then here are a couple of more situations I want to make sure are
> > > understood:
> > > 
> > > yum remove foo*
> > > 
> > > it should remove all packages starting with foo of EVERY arch or just of
> > > the primary arch in the biarch set?
> > > 
> > > yum update foo*
> > > 
> > > ditto of above? What should it default to act on
> > 
> > This is interesting.  In my mind I've been thinking of globs as broken
> > because they pull in everything.  Then I start using them when I remove
> > something and it works as I expect!  Woohoo!  Next time I use it to
> > install something and it's still "broken"....
> > 
> > Now that we've had this discussion I realize this isn't broken but a
> > design decision.  But even though I now realize it is consistent, I
> > still think it is unexpected.
> > 
> > Here's why:
> > yum install vim*
> > installs vim-common.x86_64 vim-enhanced.x86_64 vim-minimal.x86_64
> > 
> > yum install xfsprogs*
> > installs xfsprogs.x86_64 xfsprogs.i386 xfsprogs-devel.x86_64
> > xfsprogs-devel.i386
> > 
> > Why should xfsprogs install i386 packages when vim doesn't?
> > 
> 
> b/c, afaik, there is no i386 package for vim in the x86_64 tree.

Better rhetorical question:

How should I know that yum is going to install an i386 of xfsprogs but
not vim ahead of time?

I don't know that there's an i386 version of the package within the tree
until yum tells me.  So if I don't want to waste time with yum trying to
download the i386 package I need to waste time ftp'ing into the
repository to list the exact filenames of the packages I'm interested
in.

This is a case where "do what I mean" and "do what I say" don't match
up.  I think that part of it is because yum's overloading a field.  In
yum install [PACKAGE], PACKAGE sometimes means package name and
PACKAGENAME.ARCH in others.  If we break arch out of that field another
issue is easier to see:

On x86_64:

yum remove [multilib package]* will remove whichever versions of the
packages are present on the system.
yum remove [multilib package]* --arch=i386 will remove the i386 packages
if they exist on the system

yum upgrade [multilib package]* will upgrade whichever versions of the
packages are present on the system
yum upgrade [multilib package]* --arch=i386 will upgrade the i386
packages if they exist on the system.

yum install [multilib package]* will install the packages from the
repository.
yum install [multilib package]* --arch=i386 will install the i386
packages if they exist in the repository.

The install case is different from the remove and upgrade cases because
remove and upgrade deal with the installed system while install deals
with the repository.  To be truly consistent between yum install and yum
upgrade, if I had vim-common on my system and ran "yum upgrade vim*",
yum would look in the repository, discover vim-minimal, vim-enhanced,
and vim-X11 and "upgrade" those as well.  You don't have yum do that
because yum install and yum upgrade are operating in different contexts
with different expectations.  If the expectation for the install case is
"best arch for the system" instead of "all packages present in the
repository" then it shouldn't be a surprise that it isn't consistent
with the upgrade or remove case for the same reason.

-Toshio

Attachment: signature.asc
Description: This is a digitally signed message part


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