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
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
