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

Suggestion: package 'components'

  Good day!

  This is something that occured to me recently as a possible enhancement to
Debian's packaging system.  I'm actually less sure now that it's necessarily
desirable, and I can't help with implementation details (I have enough other
projects already! :) ), but I think it's an interesting idea.

  The problem that it attempts to solve is this: often packages have 'auxillary'
data which may or may not be useful to all users: for example, the Gnome panel's
sound files, or icons.  Currently, there is a mishmash of ways in which this
is solved; sometimes the offending files are broken off into another package,
sometimes (especially if they seem relatively small) they're just included
'wholesale' in the parent package.  These mechanisms actually work fairly well,
which is why I'm not sure my suggestion is necessary, but there is one other
potential glitch.  Consider, as an example, the case of translated files.  Where
do they go?  The current system, as far as I know, tends to provide them
in extra packages in 'doc', but I'm not aware of any organization.  In
particular, there's no way to tell the packaging system 'please install any
documentation or gettext files for Foo-ese with their respective packages, and
leave out the English manpages for such packages.'  My suggestion at least
provides a framework that could be used for this.

  I would suggest the creation of a new lightweight package, tentatively called
a 'package component'.  These packages could, in the simplest case, just
be .tar.gz files; control information for them (which should be very little)
would be stored in the master package. (see below)  Installing a component would
just consist of unpacking the .tar.gz file and adding the files to the
package's file list; deinstalling a component would consist of removing the
files in it.  Components would be declared in control, with details provided in
a 'components' control file.  A rough outline would be the following:

Package: MyProgram
Version: 0.0.0
Components: doc-en, doc-de, icons-gnome, wmaker-theme
Component-Suggests: doc-en, icons-gnome

Component: doc-en
Conflicts: doc-de
Description: English documentation for MyProgram
  This contains the German version of MyProgram's documentation.

Component: doc-de
Conflicts: doc-en
Description: German documentation for MyProgram
  This contains the German version of MyProgram's documentation.

Component: icons-gnome
Description: Gnome icons for MyProgram
  This contains Gnome icons for MyProgram; if you don't use Gnome you don't need
 to install it.  On the other hand, it doesn't take much disk space and you
 probably want to install it if you use Gnome.

Component: wmaker-theme
Description: WindowMaker theme for MyProgram
  This contains a WindowMaker theme based on MyProgram.

  Obviously you could trivially split the above into separate packages.
However, I have a second half to this proposition!  Making these things into
components gives the packaging system information about their relationship to
the parent package; I therefore suggest the following possibilities:

 1) Allow a program to refer to another program's components (and implicitly
   to that program) in its control file, eg:
Depends: python.net

 2) Allow two special forms, 'package.*' and '*.component' to be used.
   Especially the second form is helpful.  For example:
Recommends: *.icons-gnome
Suggests: *.wmaker-theme

  could be put in the Gnome or wmaker packages.

 3) Allow the user to specify a global component installation hint.  This will
cause the named component to be selected in any package which contains it.  For
example, German users could put:

APT::Get::Component-Hint "doc-de"

  in /etc/apt/apt.conf, and users of both wmaker and Gnome could put:

APT::Get::Component-Hint "wmaker-theme, icons-gnome"

  Does anyone else think this idea has some possibilities, or is it just


  PS - yes, this letter was -triggered- by the recent message which mentioned
     translated manpages, but I've been thinking about the problem and this
     solution for a while, I just never got arround to bringing it up.

  I used to be indecisive, but now I'm not sure.

Reply to: