On Mon, 2005-01-24 at 16:01 +0100, Michael Schwendt wrote: > On Mon, 24 Jan 2005 09:47:39 -0500, Charles R. Anderson wrote: > > > On Mon, Jan 24, 2005 at 12:59:57PM +0100, Aurelien Bompard wrote: > > > Jeff Johnson wrote: > > > > Try with rpm -i. > > > > > > Yeah OK. How about something that would be understood by depsolvers then ? > > > > installonly packages are already well understood by depsolvers. Look > > at the kernel packages. > > > > yum.conf: > > > > installonlypkgs= > > > > Nah, that's only a work-around. There's no way for a repository to flag > packages as install-only. Using the rpm install method also breaks upgrades. Say you have libfoo-1.0 and libfoo-2.0. Many apps use libfoo-1.0 and will continue to do so because it's a massive API upgrade to libfoo-2.0. think gtk1 vs gtk2. Now a security bug is found in the 1.0 branch, and the developers realize that a lot of users are stuck with apps using that branch, so they release 1.1 with the security update (as the version indicates, it's backwards compatible with 1.0), so libfoo-1.1 is released. With rpm install-only packages libfoo-1.1 would not be installed unless the user manually told the system to do it, since libfoo-2.0 is installed and is newer. The only way for this to work is make RPM recognize that libfoo-1.0 and libfoo-2.0 are completely different packages. Just because they're both libfoo is irrelevant, they are different APIs and different ABIs. In GTK's case the second version just got a two appended. Packages are gtk and gtk2. While that works, in the general case, using the soversion probably just makes more sense. The packages could be, for example, libfoo1.0 and libfoo2.0. The specifics aren't that important, just so long as it works.
