FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-17-2011, 10:20 PM
Joey Hess
 
Default RFC: bringing back task packages

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
 
Old 02-18-2011, 12:39 AM
Charles Plessy
 
Default RFC: bringing back task packages

Le Thu, Feb 17, 2011 at 07:20:30PM -0400, Joey Hess a écrit :
>
> ### 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.

Dear Joey,

it would be very exciting to have the possibility to select a blend at the
installation. To circumvent the limitation of space, how about having a single
line to select ‘Chose a Debian Pure Blend‘, that would lead to a page that
provides the full list of blends ?


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

On the other hand, I would warmly welcome an i18n task that reproduces the user
experience on Macintoshes, where a standard system contains everything to read
and write a large number of languages. Currently with Debian, on fresh
installs, I have to iterate over the missing fonts for Japanese and other Asian
languanges, and look back on my old notes to figure out what packages will
provide me an input system for chinese characters, because I select French or
English at install time.


Have a nice day,

--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110218013916.GB494@merveille.plessy.net">http://lists.debian.org/20110218013916.GB494@merveille.plessy.net
 
Old 02-18-2011, 12:49 AM
Paul Wise
 
Default RFC: bringing back task packages

On Fri, Feb 18, 2011 at 9:39 AM, Charles Plessy <plessy@debian.org> wrote:

> it would be very exciting to have the possibility to select a blend at the
> installation. To circumvent the limitation of space, how about having a single
> line to select ‘Chose a Debian Pure Blend‘, that would lead to a page that
> provides the full list of blends ?

Being able to install blends from d-i would indeed be cool. Seems to
me that there could be potentially many many tasks for the blends. For
e.g. there are 19 tasks in the Debian Med blend. There are hundreds of
Debian derivatives and many of these could become Debian Pure Blends
with some work. I would suggest some sort of search field would be the
way to go, browsing any list of blend tasks is going to be a pain.
Maybe a drill-down UI would also work, grouping tasks based on
audience; 'I am a scientist', 'I research medicine', 'I research
epidemiology', oh cool I should install tasks-med-epi to get some
tools (which are foo, bar & baz) for that. Maybe a combination of
these is the way to go.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTimS7B6vs-sMu6YeH2-+VnQOEvWrvBXtQEKFMZJE@mail.gmail.com">http://lists.debian.org/AANLkTimS7B6vs-sMu6YeH2-+VnQOEvWrvBXtQEKFMZJE@mail.gmail.com
 
Old 02-18-2011, 04:42 AM
Christian PERRIER
 
Default RFC: bringing back task packages

Quoting Joey Hess (joeyh@debian.org):

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


Many teams are definitely too small to do that (often one individual
and often someone not that deeply involved in Debian), so except for a
few "real" teams, it would probably make better sense to have i18n
(indeed often l10n) tasks maintained by the whole i18n crowd.
 

Thread Tools




All times are GMT. The time now is 06:43 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org