Re: Packaging a program with several plugins, each with different dependencies
@ 14/06/2004 12:07 : wrote Stephane Bortzmeyer :
On Mon, Jun 14, 2004 at 09:04:13AM -0300, Humberto Massa
<firstname.lastname@example.org> wrote a message of 44 lines which said:
> My solution: package the main program, the plugins separately and
> make a meta-package echoping-plugins that depends on all the plugin
> packages. HTH,
It solves several problems but not the huge increase of the Packages
file (Debian has already many packages).
IMHO, this is a problem that has to be solved in a level of its own (as
in: has no easy solution).
I'll try to explain myself: even with its 12000+ packages, there is lots
of stuff that is _not_ in Sid today, and should be (see all the ITPs and
RFPs). Many of those would warrant a more-granular packaging. As a
mental exercise only, let's say that there are 2000 upstream software
packages that deserve and would be really useful in Debian (I would say
more, but...) and let's say that 200 of those are subpackaged in an
average of 20 subpackages (some with compilation options, some with
plugins, some with tools to integrate packages, etc)... voilà: 6000 more
packages in our Packages.gz file.
My initial take on this would be: more different lines in the
sources.list, à la "progeny componentized", keeping each Packages.gz
file in a manageable size:
deb http://ftp.debian.org/debian sarge base workstation server
stable-server workstation-non-free server-non-US
Reducing the number of packages with the single objective of reducing
the size of Packages.gz is not a solution, but a new problem IMVHO.
PS: management of classes/tags of packages is yet another problem,
related only in the surface to the number of possible packages. I think
the package tagging thing is a solution on the way to this, but I'm
really not sure until I understand it fully (which is not the case right