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

Dependency madness



My system: SuSE Linux 6.4 with RPM 3.0.4

I have 2 packages -- libfoo and libbar.  libfoo requires libbar to be
installed and has the statement 'Requires: libbar >= 1.0' in the spec file.

So far so good.

I need to upgrade libbar to version 2.0 so I build the new package and do an
'rpm -Uvh ...' and receive something like:

libbar.so.1 is needed by blah
libbar.so.1 is needed by bleh

Ok, no problem.  I'll erase blah and bleh and rebuild them so they'll link
with libbar.so.2 instead of libbar.so.1.

I erase blah and bleh.  rpm is happy now and lets me upgrade libbar with
'rpm -Uvh ...'.  Next, I rebuild blah and bleh and notice 'Requires:
libbar.so.1' in the list just before source and binary packages are written
to disk.

What I discovered is that both blah and bleh (which did not have any
'Requires' statements in their spec files) depend on libfoo, and libfoo
needed to be upgraded along with libbar.  But because libfoo had 'Requires:
libbar >= 1.0' in the spec file, only the package name was in the dependency
list and rpm happily let me trash my system. :)

So the question is, why doesn't rpm generate '.so' dependencies when you
have a 'Requires: pkg' in your specfile?  Is this by design or an unintended
feature?  Or, more appropriately, has this functionality changed in 4.x?

I realize that having 'Requires: pkg' in every spec file keeps the database
size to a minimum, so perhaps it was a size/speed tradeoff issue.

So, what's the philosophical stance here?  Is it better to try and keep
track of dependencies manually (i.e. 'Requires: pkg = ver') or is it better
to let rpm handle all the dependencies itself?

--
John Ross Hunt
bigboote@mediaone.net <mailto:bigboote@mediaone.net>





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