Il giorno Tue, 9 Oct 2007 07:58:30 +0200 (CEST)
Andreas Tille <tillea@rki.de> ha scritto:
> [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,
Hi Andreas,
> 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/
We should standardize in some way the "Why" field, if we want to keep it
in our online pages (well, we could take and show it as-is, but it would be
better to organize everything).
> 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.
I don't understand, sorry. Do you mean that, for example, the "bio" task is
just a meta-package to apt-get install that throws in everything? Good :)
> 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
This analysis seems reasonable to me. I don't know cdd-dev tools, but from how
you described them, they should work like you listed.
>
> ...
>
> 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 ...
I think that the APT interface is better. I mean, at least for packages already
in Debian. APT gives versions in various distributions (see apt-cache policy),
maintainer, uploader, short/long descriptions, homepage, ... . Everything that
we should _NOT_ add to the tasks file. Keep it simple ;).
> 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.
> - ...
This for not-yet-in-mirror packages, right?
> Kind regards
> Andreas.
Kindly,
David
P.S.: you know I'm at university now. I won't have connectivity for all the
week, only on weekends. Maybe I'll have an ADSL in Palermo, but I don't know if
and when. I'm sorry I've slowed down the website growth :(
--
. ''`. Debian maintainer | http://snipurl.com/qa_page/
: :' : Linuxer #334216 | http://www.hanskalabs.net/
`. `'` GPG: 1392B174 | http://www.debianizzati.org/
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
Attachment:
signature.asc
Description: PGP signature