[Fedora-packaging] are subpackages required for optional loadable libraries?

[Toshio Kuratomi]

John Dennis wrote:
> I presume the reason we've historically 
> created these little subpackages is to deal with dependency issues.
> 
Yep.

> 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.

[snip]
> 
> 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

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 
dependencies.

3) What is the default level of functionality that should work out of 
the box?

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20080226/a7875e2d/attachment.sig>