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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
