John Dennis wrote:
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?
I'm inclined to say it depends. A specific package would help.
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
This is what a packager is supposed to do, however... deal with the pain
so that the user gets the best experience possible.
and it's going to be a headache for users trying to install,
they're going to have to deal with lots of subpackages.
This is the real concern, I'd think. We want to make user's lives as
easy as possible. In some cases this means we need to break up a
package and in other cases we don't. For instance, I would say that
most packages that have a separate plugin for each of postgres, mysql,
and sqlite need to have those plugins separated into different
subpackages as an end-user is most likely going to be using one of the
above databases, not all three. In this case, the subpackages should
also depend on the libraries necessary to make it work right out of the box.
OTOH, there's a package like python-sqlalchemy which provides a database
abstraction and ORM library for programs to use. It doesn't make sense
for this library to depend on all three of postgres, mysql, and sqlite
when it can work equally well with any of them.
So the questions I'd see us needing to address are:
1) What are the criteria to split a package into multiple subpackages as
opposed to keeping modules in a single/few subpackage.
2) When a subpackage is not split, should Requires be used to pull in
all of the dependencies or should they be used to pull in none of the
3) What is the default level of functionality that should work out of