How to handle mgltools in our tasks files
- To: Debian Med Project List <firstname.lastname@example.org>
- Subject: How to handle mgltools in our tasks files
- From: Andreas Tille <email@example.com>
- Date: Thu, 6 Nov 2008 11:45:36 +0100 (CET)
- Message-id: <alpine.DEB.2.00.0811061037020.24185@wr-linux02>
Steffen Möller decided to mention only autodocktools in our tasks files which
create meta package depenendencies. This implicitely installs several
mgltools-* packages via the depencencies of autodocktools. This is fine
if we only consider the med-bio package as result of the information inside
the tasks files.
But recently some other tools were developed which use the tasks file as
a source of information as well and currently these tools just ignore all
mgltools-* packages because they are not mentioned in the tasks files.
So I would like to hear your opinion about what should happen in the
following use cases of the tasks files:
1. Web tasks pages:
Does it makes sense / would it harm the tasks pages if all the
mgltools would be listed there (either in bio or bio-dev task)?
2. Bugs pages:
The pages should be really watched here (either in task bio or
bio-dev) and probably in the status "Depends" because a dependent
package depends on them.
3. QA overview:
The packages should be listed really in either bio or bio-dev
section instead under "non-free".
If the question 1 (tasks pages) would be answered with: "Yes, it makes
sense to list mgltools-* packages as *Depends*" every other issue is
solved. There is no practical change inside the metapackage med-bio
because the effect whether it depends directly or indirectly from the
packages in question would be the same.
If question 1 is answered with: "No, these packages would just spoil our
task list and also do not belong to the bio-dev task" we might need an
extra field which indicates packages that should be listed on the bugs
pages and QA pages but not on the tasks page. This extra feature for
the webtools stuff is not really hard to implement - but we should just
discuss whether this is a feature we really need.
So what solution would you prefer to be able to keep an eye on these