RPM -- plans, goals, etc. [LWN.net]

RPM -- plans, goals, etc.

Posted Dec 19, 2006 11:52 UTC (Tue) by seyman (subscriber, #1172)
In reply to: RPM -- plans, goals, etc. by cortana
Parent article: RPM -- plans, goals, etc.

> At the risk of starting a huge OT discussion... why?

Because the dependencies for a package can be in any number of packages, all of which would resolve them.
If I need the mysql client libs, it doesn't matter whether the package is called mysql-client or MySQL-client or anything else. It just matters that the library that I'm linking against is installed on my system.

> How does 'foo depends on /usr/lib/libbar.so.3' express the fact that foo uses symbols that were introduced into libbar.so.3 in version 4.2?

Package dependencies should be used for symbol versioning but these should compliment file dependencies, not replace them (IMHO, of course).

(Log in to post comments)

RPM -- plans, goals, etc.

Posted Dec 21, 2006 13:42 UTC (Thu) by cortana (subscriber, #24596) [Link]

This only seems to be an issue because of the lack of a standardised method for determining the proper dependencies that a package should end up with. In Debian, if I was packaging a program that links against libmysqlclient.so.15, during the package build process I would use the dpkg-shlibdeps program which basically does this:

cat /var/lib/dpkg/info/*.shlibs | awk '$1 == "libmysqlclient" && $2 == "15" {print $3, $4, $5, $6, $7, $8, $9}'. (Does anyone know a better way to tell awk to 'print the rest of the line', BTW?)

The output is libmysqlclient15off (>= 5.0.24-2), which I would use directly in the package's Depends field.

Here's a more typical example:

$ dpkg-shlibdeps -O /usr/bin/mysql shlibs:Depends=libc6 (>= 2.3.6-6), libgcc1 (>= 1:4.1.1-12), libmysqlclient15off (>= 5.0.24-2), libncurses5 (>= 5.4-5), libreadline5 (>= 5.2), libstdc++6 (>= 4.1.1-12), zlib1g (>= 1:1.2.1)

RPM -- plans, goals, etc.

Posted Dec 21, 2006 13:49 UTC (Thu) by Randakar (guest, #27808) [Link]

> Because the dependencies for a package can be in any number of packages,
> all of which would resolve them.

That's bogus. It's easily possible for different packages to provide the same file with -different- contents. deb packages simply say 'Provides: foo' in their package headers if they want to give users a choice of packages.

File dependencies however plainly don't cover a number of cases, like kernel versions with or without certain features, udev revisions (which can 'add files' in /dev without actually packaging them), certain types of library conflicts..

Personally I think all those RPM people just have no idea what they're missing out on with .deb.

Worse, instead of just saying 'argh, this project was abandoned, but hey look, we have a great alternative with DPKG' they embark on something that can only lead to massive duplication of effort.