New use of task files (Was: Proposal :))

[Andreas Tille <tillea@rki.de>]

[Some interested CDD-Ians in CC because this in principle should go to
 the debian-custom list but I'm afraid it would miss some people in
 Debian-Med that are deeply involved.  I'll post a summary there once
 discussion is settled down.]

Hi,

over night I had another idea how we could get a better grip on automatically
observing software that is not yet packaged in Debian but on our todo list.
Currently the source of the debian-med meta packages contains so called task
files as input for cdd-dev tools:

   http://svn.debian.org/wsvn/cdd/projects/med/trunk/debian-med/tasks/

It contains Dependencies from packages.  The cdd-dev tools verify that
these Dependencies can be fullfilled in Debian main and if not these are
turned into Suggests.  So if any package that is listed in the task file
is not (yet) available at the Debian-Mirror it is just suggested in the
Meta package.  What would be the effect if we (intentionally) put not
yet existing packages into the task files:

  1. For inofficial packages (that might be anywhere on an apt-get able
     archive in the net and exists in the users sources.list:
      The package is installed if the user enables suggests, even if
      it is not in official Debian.
     -> positive
  2. For not yet existing packages that are ITP/RFP ed as WNPP bug:
      Once the WNPP bug will be closed the package is automatically
      drawn in without changing the meta package.
     -> very positive because debian-med developers will not forget
        to include the new package (which unfortunately happened in
        the past - shame on me)
  3. For software that is not packaged at all:
      Nothing will happen (at least to my knowledge)
     -> no harm done

So from my point of view it should be done.  But we could gain even
more if we draw this concept further.

There could be additional information added to the tasks files - I just
wonder whether we overstretch the scope of these task files or whether we
should take them as our main source of information.  Here are some ideas:

  1. The cdd-dev tools could install these files into say:
       /usr/share/cdd/${CDD}/tasks   (in our case CDD=med)
     of a the general ${CDD}-config package.  This would enable
     tools like David's online tools to parse these directly
     instead of using the apt-get interface which might give
     some gain of spead but more importantly some extra information
     like ...
  2. Add some extra information that is ignored by the meta package
     building process but is interesting for our work:
      - WNPP bug number (if exists)
      - URL of homepage / download
      - License
      - Short description
      - Long description
      - Remarks like: Actively developed, complex software,
        dead upstream, etc.
      - ...

IMHO, this is very important stuff end would enable us to automatically
generate a lot of stuff that enables us to keep a good overview over
things we have in our focus for future work.  I admit I lost a little
bit the overview I once had when I started working on our todo list
on the web pages and feel even stronger that we have to do some work
to keep this list manageable when facing a growing number of interesting
projects to include.

Any thoughts?

Kind regards

         Andreas.

--
http://fam-tille.de