On Fri, 8 May 2009, Lucas Nussbaum wrote in [1]:
Those tasks are read from the Packages files (the Task: field that some
entries have). I'm not sure how this field is managed.
When trying to track down the origin of the task column in UDD[1] I learned
that it is just copied from the task field in the packages file which is
maintained via tasksel. Please excuse my ignorance but I was simply not
aware that we have such a lot (>300) tasks defined in tasksel - I stupidly
assumed we would have these two hand full which are displayed in the end
of Debian installer.
When reading tasksel-2.78/tasks/README I stumbled upon:
Care should be taken when adding new tasks to ensure that the new task is
suitably generic -- it should be something of value to a large number (at
least 25%) of our users;
and than looking at the tasks which are supporting more than 10 different
languages I can plainly assume that the criterion "at least 25% of our users")
does definitely not fit - without discriminating any specific language it
is not realistic to assume that amharic, arabic, basque, belarusian, bengali,
bosnian, brazilian-portuguese, gujurati, hebrew, hindi, ...) is useful
for 25% of our users each. Because I think it is important to support
all these languages we should at least fix the readme accordingly.
Mentioning this I wonder what might be a reasonable criterion (and I
wonder whether this list is apropriate because debian-boot is mentioned
as maintainer for tasksel - but I do not see this issue as an
installer specific topic and thus I'd like to keep the discussion here
on this list).
When wearing my Debian Pure Blends hat the term task has some slightly
differnet meaning because each Blend also defines a certain set of tasks.
The same term is used intentionally and historically because the Debian
Edu Blend used to create tasksel input file from a set of tasks files
and thus the source packages of a Blend package like debian-edu, debian-med
etc just contain a tasks directory containing valid tasks files - even if
some more fields were added and interpreted by the Blends tools. One
part of the output of blends-dev is a *.desc file which is installed to
/usr/share/tasksel/ - so in Debian Pure Blends we using the same technique
but have a different way to propagate the data (inside a $BLEND-tasks
binary package).
My question is now how we might possibly move the information of Blends
tasks into the Packages files. Well I learned that people here are
concerned about even more information in packages files and I just
assume for a moment this is a wanted behaviour, but for sure this is
a question which should be discussed as well. My main interest is to
get the information about tasks in to the packages table of UDD. I
just would not be happy to have different methods to feed this information
into UDD - thus I would prefer the established method via simply parsing
the Packages file.
I see two options to move Blends information to the packageas file:
1. via tasksel
The blends-dev could be used to create a patch against
tasksel and ask tasksel maintainers to include this into
the tasksel source. The $BLEND-tasks package might be droped
in favour of the information which is provided by
tasksel (>= version including the patch)
Pro:
We could profit from the established way to propagate
Task information to the Packages file.
Con:
We loose some flexibility in Blends.
2. implement own way to populate info to Packages file
The blends-dev package could move the needed information
somehow following the way tasksel is doing. I have read
that this is done by editing override files - I have no
idea whether this is up to date information.
Pro:
Each Blend remains flexible and we do not require
any action from tasksel maintainers after releasing
every single new Blend release.
Con:
We need a new way to push task information to
Packages files.
I slightly tend to prefer the second option but I'm not educated
enough about possible problems that might occure.
What do you think? What do you think about the third option to
just update the packages table in UDD from a different source than
the packages files? In principle we also could add another table
tasks - but I would prefer the same technical implementation for
what is finally technically identical: Just selecting a set of
packages.
Any comments are welcome.
Kind regards
Andreas.
[1] http://lists.debian.org/debian-qa/2009/05/msg00008.html
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
