On Wednesday, 27 February 2008 at 02:23, John Dennis wrote:
Historically when a package includes optional support via a loadable
module
we've put the loadable module in a subpackage. For example a package might
include a module supporting mysql so we would create a mysql subpackage
which contains the mysql loadable module and the subpackage would require
mysql. I presume the reason we've historically created these little
subpackages is to deal with dependency issues.
But suppose your package includes dozens of optional loadable modules does
it still make sense to create dozens of subpackages?
IMHO it does make sense. I know disk space is cheap, but still I prefer
to keep my system free of any unnecessary stuff.
It starts to get unwieldly really quick.
What exactly is the problem?
Is it permissible to skip all the subpackages, have
the rpm include all the loadable modules, and put the onus on the user such
that if they edit the main package's config file to load the mysql module
it's up to them to make sure the mysql libraries are installed?
Here's another issue: Suppose the package puts it's loadable modules (e.g.
.so's) in it's own subdirectory for loadable modules. RPM's automatic
dependency checking seems to completely miss all the external libraries
needed at run time to load one of the modules and resolve all it's
references. The net result is none of these external dependencies get
picked up at all. Is that O.K.? How does one deal with that in a spec file?
The answer to this question probably drives the answer to the first
question.
I find it odd that it doesn't find the dependencies on external libraries.
Could you show the package to us? It may be a bug in the dependency generator.
FWIW, the upstream spec file does not create a subpackage per
loadable
module. It does create a subpackage containing all the loadable modules.
When we build the loadable module subpackage the resulting rpm is missing a
lot of the external dependencies on external .so's. That's unfortunate but
I'm thinking it's the only practical way to deal with it. Trying to factor
out all the dependencies will be a packaging nightmare and it's going to be
a headache for users trying to install, they're going to have to deal with
lots of subpackages. At least with the scheme where all the loadable
modules are in one subpackage you won't pull in stuff you don't want or
need, but at the expense of not pulling in something you might need.
Comments?
Well, without seeing the package, it's difficult to comment on this.
I still think it's desirable to split the parts that require additional
external libraries as much as possible.
Regards,
R.
--
Fedora contributor
http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor
http://rpm.livna.org MPlayer developer
http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"