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.
Descrip
