Toshio Kuratomi wrote:
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.
I say that varies too much from package to package, I believe that in the end
that is best left to the packager, I see no way we can sanely regulate this. So
we shouldn't try to write rules / procedures for this. All we need is a
procedure how to handle disputes between a bug-reporter and a packager, when
they cannot agree on wether to split / not to split.
As long as there is no such dispute I would like to see the FPC not looking
As for the toplevel poster, please name the package and describe the exact
situation, trying to generalize this problem is not a good idea.
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
When using plugings, the .so files should have all there dependencies
installed, if you don't want those deps in the main package, put the plugin in
However when a program is designed to have increased functionality by directly
dlopening a library (as oposed to a plugin where the plugin is linked against
the library), then you should probably not Require the library, but in cases
where the program is pretty crippled without it you might add a Requires for
the lib. This leads me to the conclusion we really need something like
recommends, so that diskspace / bandwidth restricted people can install a light
version, and "normal" users just get all functionality of a package.
3) What is the default level of functionality that should work out of
Varies from package to package.