Re: New use of task files (Was: Proposal :))
On Fri, 12 Oct 2007, David Paleino wrote:
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).
I agree with the suggestion to organize everything, but actually the
"Why" field is something I would regard as pure comment inside the task
file that should not be propagated to the web pages. I would rather
ass new tags like for instance "responsible Maintainer" (in contrast
to the often group maintained packages that kind of hide the real
person that is the most active developer), "License" (as long as
debian/copyright is not automatically parseable), "Homepage", etc.
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 :)
The bio task is the "source" for the med-bio package. The task file is
parsed by cdd-dev and all package that are mentioned as Depends/Recommends
in the task file will be turned to Recommends (we agreed not to use strict
Depends in meta packages any more) in the meta package - provided that this
package is available via sources.list. Other packages from the tasks file
are mentioned as Suggests.
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 ;).
Perfactly true. Apt should be the real reference for all existing packages.
I just locked a little bit into python-apt (which is unfortunately poorly
documented) and I hope to come up with a prototype after the Extremadura meeting.
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?
Exactly.
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 :(
Don't mind about this. You did the first push and nobody will blame you
for doing your studies.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: