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

[comp.os.linux.misc] RPM - possible improvement



Sorry about the forward, but I though some of you might enjoy this
from USENET; the guy is essentially (without knowing it) asking for
RPM to be more like dpkg...

(I followed it up on USENET.)


Steve
dunham@cps.msu.edu

--- Begin Message ---
After some fight with RedHat package management system and reading
reports about other such battles in this newsgroup, I got an idea,
what is missing from RPM format.

Imagine situation no 1. Some package, say prn-filter, depends
on other package, say ghostscript. Really it doesn't care, which
version of ghostscript you have as long as executable is named
/usr/bin/gs
and understand certain command line options.

Situation no 2. You are upgrading package, say tcl7.6p2 to say tcl8.0
There are some packages, which depends on libtcl7.6.so, but nothing prevents
you from keeping it along with libtcl8.0.so, as long as package system
understands that you have fully installed tcl8.0 and some vital part
of tcl7.6p2.

Situation no 3. You are upgrading tcl8.0 to tcl8.0p1. (it would
probably happen next month) Author of package definitely knows, that it is
bugfix release, and nothing would be broken by substituting one file instead
of another. But how to explain this to rpm.

Situation no 4. I'm upgrading libc.so from 5.2.x to 5.3.44. It would
definitely break package "Cyrillic-locale", but the only thing I need to
fix this is to rebuild this package from sources. 

So I suggest:
1.add more flexible system of versioning (something like Tcl package manager),
which would allow author of rpm specify, that upgrade to this version
wouldn't break dependencies, if there are some packages which depends on
certain previous versions of same package.

2.On other hand, author of package should can specify, how this package is
depending on other: it requires version so-so and above, version so-so and
any other with same major number, or exact version of package.

3. Provide way to specify, that some critical files could be left from
previous version after upgrade in order to keep dependencies of other
packages. It especially concerns shared libraries. 
Again, it is up to package maintainer to specify, which files should be
left, if dependencies would otherwise be broken and where they are left.

4. Ideally, user should be notified when rebuilding of some package
from source RPM can fix dependencies, broken after upgrade.
(I'm not sure that it is possible at all, but would like this feature 
if it appears)


--- End Message ---

Reply to: