[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rpmorg-list
Subject:    Re: rpm -U  and -e atomic operation?
From:       bob () proulx ! com (Bob Proulx)
Date:       2005-06-27 0:56:07
Message-ID: 20050627005607.GB18399 () dementia ! proulx ! com
[Download RAW message or body]

Jason Pyeron wrote:
> my apologies, for my error in posting to this last night.

I actually responded to this message previously.  But it seems that
all posts over 4k to this mailing list are discarded without review
and my message was lost.  Sigh.  I will keep this one short.

> so lets say we have the following packages name{provides,provides}:req,req.
> foo-3.00-0{/lib/foo.so,/lib/foo.so.3.00}
> FooByNewName-4.00-0{/lib/foo.so,/lib/foo.so.4.00}
> packageX-1-0{}:/lib/foo.so.3.00

Okay so far.

> FooByNewNameCompat-4.00-0{/lib/foo.so.3.00}:FooByNewName=4.00

You have already created a previous packaged that requires
foo-3.00-0.  But now you are trying to replace the old library with a
new library.  The information configured in your package is that if
lib-3.00-0 is not installed that your program will be broken so rpm
won't allow the operation of removing it.

> rpm -q --whatrequires foo.so.3.00
> packageX-1-0
> 
> what is the PROPER way to do
> 
> rpm -U FooByNewName-4.00-0.rpm FooByNewName-4.00-0.rpm
> 
> PROPER means no --force --nodeps, etc... and reinstalling packageX would 
> not be an option.

Don't try to include foo version 3 and foo version 4 both in the same
package.  You should create a new package called foo4 that implements
only the version 4 functionality.  Leave the old foo version 3 package
installed and install the new package in addition to the old package.
Your old program will continue to work because it is using the old
library.  You can move forward with a new package.

See the packaging for gnulib in glib and glib2 for examples.

  rpm -qf /usr/lib/libglib-2.0.so.0 /usr/lib/libglib-1.2.so.0
  glib2-2.2.3-2.0
  glib-1.2.10-11.1

> The best I have come up with is making an faux rpm named foo which 
> obsoletes foo-3.00-0 but provides nothing.

Without repackaging and releasing your old package and have it depend
upon a virtual ABI version you can't.  But I know I would not want to
do that so that is okay.

There are some people who like keeping the same package name and only
incrementing the version.  Then --install the new library instead of
using --upgrade.  As long as the files do not overlap this works.  But
I don't like it because it adds a lot of complexity.  You have to
remember handle the installation, versions upgrading, of some packages
specially.  Instead I would change the package name (e.g. libfoo4) and
allow automated upgrades to work.

Bob

[prev in list] [next in list] [prev in thread] [next in thread]