Re: RPM's are bad

[Owen Taylor <otaylor redhat com>]

Dennis Bjorklund <dennisb cs chalmers se> writes:

> On Fri, 20 Oct 2000 jgotts linuxsavvy com wrote:
> 
> > >A harder problems is that we would like to have packages that can be
> > >installed with different versions in the same time. I have gnome-print
> > >0.20 installed and I have other packages that needs
> > >/usr/lib/libgnomeprint.so.6. So now I cant upgrade to gnome-print-0.24 and
> > >therefore I cant use newer programs that needs 0.24.
> > 
> > This is an unavoidable problem.  When API's change, bumping library version
> > numbers is the right thing to do.  Distributions sort this out for you.
> 
> Sure, but shouldn't we try to create packages that you can choose to keep
> installed so that old programs still works. For some packages people have
> created new rpm's that allow that. For example there is gtk+10 packages
> for those who have installed gtk+ version 1.2. And I guess that when gtk+
> version 2.0 comes someone will create gtk+12 packages. Why not create
> packages that we can keep in the first place.

Well, the Red Hat packaging policy is to always name the current
package for a library without a version, and then have compatibity
packages with a version. 

The main reason for this is that so, when doing an upgrade,
the new version can automatically be installed. The Red Hat
upgrade is smart enough to know that if upgrading gtk+ will
remove libgtk+-1.2.so.0 that installed programs 

I personally slightly prefer the Debian version where the version
number is always in the library, and have argued that internally a few
times, but thats swimming upstream against tradition. 

Note that with Red Hat you CAN have multiple versions of a package
installed, as long as they don't have file conflicts; so there
isn't as much of a problem as with Debian packages; as long
as users know to install the package with rpm -ivh instead
of rpm -Uvh, then you don't need compat libraries - they are
mostly a convenience.
 
> If we look at gtk+ as an example we se that there is even more
> problems. The gtk+10 package does not contain the locale files. Then are
> named for example /usr/share/locale/sv/LC_MESSAGES/gtk+.mo. I guess that
> old programs that still uses gtk+1.0 will use the new .po files which
> might not be a good idea..
> 
> So how can we have several versions of gtk+ installed? We should probably
> include the major version number in the path there.

We've worked hard on resolving these problems for GTK+-2.0 and
and basically everything is versioned to allow multiple developmnent
environment and runtime installations:

 - libraries 
 - po files (The domain for GTK+-2.0 is "gtk+20")
 - configuration file locations
 - header file installation directories
 - gtk-config binaries and package-config files
 ...

This will be the standard for other GNOME libraries in the future.

> Then we also have themes which probably should be solved in the same way,
> but one problem at a time. But these problems have to be solved by the
> programmer, not only the one who packages it.
> 
> I feel that for core libraries, that many other programs use, we really
> need to be able to have many versions installed (including translations).

Agreed.
                                        Owen