[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
 <humberto.massa@almg.gov.br> 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

etc.

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 now).


--
br,M



Reply to: