Dominik 'Rathann' Mierzejewski wrote:
On Wednesday, 27 February 2008 at 03:55, 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.
Plugins implementing the same functionality using different external libraries
(database engine support plugins are a typical example) must be packaged
separately. A developer testing if the software works equally well with all
supported DBEs will just have to install all of them by hand. We'll assume
he's competent enough to do it.
If the plugins do different things, it should be left for the
decide. Meta-packages come handy here (and are my preferred solution).
Not sure here. When coupled with the answer to #2 I think we should
have some guidance (packager gets final say but still some guidance)
We want the packager to know that leaving multiple disparate plugins in
a single package should have benefit to the end-user. If it doesn't
help the end user to have a single package then they need to break it
up. It can be a lot of work to package correctly but that is what the
packager is agreeing to when they submit a package.
> 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
All, of course. Otherwise we end up with bugreports saying the plugins
don't work (because we intentionally crippled them).
> 3) What is the default level of functionality that should work
out of the
That should be left for the packager to decide.
I think we need guidance here as well. For instance, if a web
application needs a database to work out of the box but that database
could be any of mysql, postgres, or sqlite, do we require that one of
those be installed?
So... I don't see anything here that needs to go into the Guidelines but
I do think there's some stuff that should be thought about and go on the
wiki as recommendations of how to tell whether a subpackage needs to be