Dominik 'Rathann' Mierzejewski wrote:
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.
Using the scheme upstream uses (a subpackage with all the loadable
modules) you won't pull in any unnecessary stuff.
It starts to get unwieldly really quick.
What exactly is the problem?
Creating a lot of subpackages, figuring out the dependency list for each
of them, and then asking the user understand which of many subpackages
he really needs, something which changes when he edits the main packages
config file which changes the set of loaded modules.
I see two potential complaints, each representing one end of a spectrum:
1) The main package is broken, it pulls in stuff I don't want (your issue).
2) The main package is broken, every time I try running the package in a
different configuration I have to install some other subpackage, why
can't they all just be there so I don't have to figure it out? (btw,
figuring out which subpackage is needed means knowing enough to look for
errors in the daemon's error log when it doesn't start successfully,
that doesn't seem very friendly either).
--
John Dennis <jdennis@xxxxxxxxxx>
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
