A long time ago, tasksel installed task packages, which were regular metapackages. This was dropped because the task packages had to Depend on many packages, which made the installed system brittle, and made testing propigation a problem. Now that Recommends are installed by default, I'm revisiting the idea of using task packages. It solves many issues and inconsistencies with tasksel vs the rest of Debian.
The other problem with task packages before is that tasksel allowed the
user to select from amoung all that were available, and this resulted in a
confusing long mess of tasks to choose from. To avoid that, I intend to
keep the ultimate decision about what tasks are displayed in tasksel under
the control of the tasksel maintainers. But, I do hope that moving more of
the maintenance of tasks to the developers responsible for those areas of
Debian will result in a better selection of software and less work. We've
already had some good progress in that area with the gnome metapackages
which are used by tasksel.
If tasksel was switched to task packages, the task packages would probably
be initially built from tasksel's source. They could be split out of
tasksel's source as other groups stepped up to maintain them.
## Questions for teams
### gnome
Would the gnome team want to maintain a task-gnome?
Much of tasksel's gnome task is already taken from the gnome-core
and gnome metapackages, with a few more things added. task-gnome
would not need to deal with core X desktop stuff; task-desktop would
still handle that. Although we could move away from having a task-desktop
if you'd prefer.
There are also many localized desktop tasks. Mostly these add things
like localization packages for openoffice, and occasionally some fonts.
I'd like to see those be maintained in conjunction with task-gnome,
but it would mean some coordination with the dozens of people who
currently maintain those localization tasks.
### kde, lxde, xfce
See above and s/gnome/$you/
### cups
Would the cups maintainers be interested in maintaining a
task-print-server? Keeping the right ppds and cups packages in the task
has been an ongoing issue for me.
Note that a subset of cups is also installed as part of the desktop
tasks, and it would also make sense to have a metapackage on the cups
side that desktop tasks could use. The sole different currently is
that openprinting-ppds is included in the print server task, but not
the desktop tasks.
### blends
I think there is interest in getting some blends displayed in Taskel?
It's mostly orthagonal to this proposal, but this would help with
giving you full control over what your tasks do. I do feel that blends
need to be listed below the other tasks in tasksel, and probably with
a divider between them. Also, we have been careful to only have ten
tasks, to avoid overloading the user; and there is a limit to the length
of the list before it begins scrolling, so the d-i team would have to
look at the UI before adding Blends to the interface.
### i18n
There are many language tasks in tasksel. It might be good to have
the task packages be moved out of tasksel; I don't know if it'd make
sense to have individual language teams maintain them, or what.
If tasksel displayed Task packages' short Description fields, those
would need to be translated. I know we have translated Descriptions
but I don't know about coverage, or if that info is available when
tasksel runs in d-i?
## Comparing tasksel and dpkg fields
Key -> Depends
This would be an improvement, as new Depends of a task would be
installed on upgrade; there is currently no way to upgrade a task
and get new packages that have been added to it.
Note that Britney already treats Key as Depends internally.
So this change would not impact testing migration.
Packages -> Recommends
Recommends may be better than what we have now in tasksel.
If aptitude auto-selects *new* recommends of a previously installed
package to be installed? Currently new Packages added to a task
only affect new installations of that task.
Most packages in a task need to be Recommends, to avoid wedging
Britney, and to allow removing bits of a task that are not wanted.
Note that the Task field on the package side, which is added to the
archive based on data from tasksel, could go away.
Enhances -> ???
The Enhances fields are not truely the same as Depends
(but are probably closer to Depends than to dpkg's Enhances).
A task that Enhances other tasks is hidden, and
auto-force-installed when the other tasks are installed.
Relevance -> ???
This is used to do some UI ordering of tasks. Closest equivilant
is Priority, but it's not granular enough.
Test- -> ???
These fields specify programs to run to test if the
task should be force-auto-installed, or hidden, or selected
for installation.
Description -> Description
Note that tasks' short description needs to be carefully worded
since it appears in a short, low-jargon list of tasks in tasksel.
For example, "Graphical desktop environment", "Web server",
"DNS server", "Laptop". The long description can say that it's a
task package, and provide arbitrary detail (but tasksel doesn't
display it).
Perhaps tasksel should only display part of the short description.
Then we could have "task package: Web server". I don't know if
this buys much, and it makes handling translated descriptions
fragile.
Section -> ???
This field is currently one of user, server, or l10n.
It is only used by aptitude. It could be dropped, as aptitude
probably won't be displaying task packages in its "Tasks" section.
Unless it has some metadata to know that packages are tasks..
## Implementation Option A
Put everything in the task package.
Test-* -> XB-Task-Test-*
Enhances -> XB-Task-Enhances
Relevance -> XB-Task-Relevance
Section -> (remove)
tasksel-data would then contain only a list of task packages that should
be displayed, and no other information need be maintained. This
informaton would still be provided by debian-tasks.desc, but in a much
reduced format from what is there now. I want to retain debian-tasks.desc
since it is designed to be overridable and extensible to meet needs of
derivatives.
This would limit interaction between task package maintainers and tasksel
maintainers to communication about what tasks meet criteria to be shown
in tasksel.
## Implementation Option B
Keep Test-*, Enhances, Relevance, and Section in the debian-tasks.desc
file; move the other fields to the task packages.
Some ongoing interaction would be needed between task package maintainers
and tasksel maintainers. Enhances and Relevance would be the fields most
likely to need to be updated in tasksel to reflect changes in the task
packages.
--
see shy jo
signature.asc
Description: Digital signature
