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? It starts to
get unwieldly really quick. 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.
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?
--
John Dennis <jdennis@xxxxxxxxxx>
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
