Re: RFC: bringing back task packages
Quoting Joey Hess (jo...@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. signature.asc Description: Digital signature
Re: RFC: bringing back task packages
Le jeudi 17 février 2011 à 19:20 -0400, Joey Hess a écrit :
### 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.
Yes, they fit globally the same purpose. There are just some small hacks
to handle tasksel; for example we allow OOo as an alternative to
gnome-office to avoid installing both by default when OOo was already
selected by the desktop task. I don’t think anything needs to change on
that matter.
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.
I’d prefer to keep it separate. The gnome metapackage should be
installable on a session server without any X server installed.
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.
I’m afraid the approach of using tasks for localization does not scale.
Instead, I’d like to see introduced something like conditional
recommends: that is, recommends that would only be installed if a
third-party package if already here (and that would get installed when
installing the said third-party package).
This way, you could do in all packages something like:
Package: aspell
Conditional-Recommends: aspell-en {task-english}, aspell-fr
{task-french}, …
This would also be useful for some plugins. I don’t know how hard this
would be to implement in APT.
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.
AFAIK new Recommends are not installed. That is the reason why we still
heavily use Depends in metapackages instead.
Cheers,
--
.''`.
: :' : “You would need to ask a lawyer if you don't know
`. `' that a handshake of course makes a valid contract.”
`--- J???rg Schilling
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1298020358.18394.59.camel@meh
Re: RFC: bringing back task packages
On Fri, Feb 18, 2011 at 10:39:16AM +0900, Charles Plessy wrote: ### 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, A meta-package that installs fonts that provide a glyph for every code point in Unicode would be great. Preferably something better than ttf-unifont that supports only Plane 0 and is butt-ugly. If you do anything related to i18n, having fonts that at least resemble what would be used by users is a must. 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. On the contrary, I don't see what an input system would be good for. How many languages can you write? I can do a few languages with the Latin script and some basics of Cyrillic -- but even that with a phonetic keymap, stretching my remnants of Russian lessons from the elementary school. Such a task would be useful only for installs that are meant to cater to many users from all around the world -- a very rare occurence, while cluttering and potentially slowing down the systems of everyone else. I do believe that every developer who does something even remotely related to displaying text that might possibly behave different for double-wide, combining, etc, characters (including for example every single curses program), has a duty to at least briefly check if these work correctly. However, for input, unless you do something low level, pasting text works just as well and is so much simpler if you don't know the script in question. Having two such tasks in tasksel would be needless clutter, but at least on metapackage level, let's have output and input separated. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110218095105.ga16...@angband.pl
Re: RFC: bringing back task packages
Hi, On Freitag, 18. Februar 2011, Charles Plessy 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 ? and then probably a sub page again, ie Debian Edu has 6 different profiles to install (which can be combined just like tasks). cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: RFC: bringing back task packages
[Not sure whether we should keep the long To: - list, I'd suggest continuing on debian-devel but keep it for the moment.] On Thu, Feb 17, 2011 at 07:20:30PM -0400, Joey Hess wrote: 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. If I understand the consequences of the statement correctly I welcome this step very much. ### blends I think there is interest in getting some blends displayed in Taskel? Yes, definitely! 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. This would be an acceptable approach. 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. The requirement for a limited set of tasks to provide a good overview is reasonable but has two flavours: On one hand it restricts the number of Blends we can include into the list and on the other hand it might have an influence on the number of tasks[1] we are maintaining inside each Blend which exceeds 10 drastically at least for three Blends (the most active ones). From my perspective the only reasonable solution for this reduced number of list entries requirement is to close bug #273797 and have a hierarchical task selection where you first select the Blend and than select a set of tasks[1] inside the Blend. [1] Remark: I have the feeling that in the Blends context we are using the term task in some different manner. While it was probably influenced by tasksel (and invented by the Debian Edu developers) it drifted a bit away somehow. I have the feeling that we should find a proper definition what we mean when talking about Blends. ## Implementation Option A Put everything in the task package. ... ## Implementation Option B Keep Test-*, Enhances, Relevance, and Section in the debian-tasks.desc file; move the other fields to the task packages. I'm afraid I do not fully understand the difference / consequences of these two options. Can you provide some short examples? Kind regards Andreas. -- 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 Archive: http://lists.debian.org/20110218134908.gh9...@an3as.eu
Re: RFC: bringing back task packages
Le Fri, Feb 18, 2011 at 10:51:05AM +0100, Adam Borowski a écrit : On the contrary, I don't see what an input system would be good for. How many languages can you write? The one from the country where I was born, and the one from the country that was kind enough to give me a work visa :) Such a task would be useful only for installs that are meant to cater to many users from all around the world -- a very rare occurence, while cluttering and potentially slowing down the systems of everyone else. At least for Japanese, the input system is not active by default when starting GNOME with a French or English locale. One has to enable it, for instance with im-switch. I do not know how invasive are other input sytems. But if they are not, I thing that they could be part of a ‘I have disk space’ i18n task. I would not mind spending a couple of gigabytes if this would make my computer ready for use for anybody on this planet. For this, we need also to install most translations available. This is one of the rare things I miss from Macintosh. I always feel sorry that, while when I borrow a Mac I can switch it to French, when I lend my Debian, people can not switch it to Japanese unless I prepared it in advance. Have a nice day, -- Charles -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110219040416.gc18...@merveille.plessy.net
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110218013916.gb...@merveille.plessy.net
Re: RFC: bringing back task packages
On Fri, Feb 18, 2011 at 9:39 AM, Charles Plessy ple...@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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktims7b6vs-smu6yeh2-+vnqoevwrvbxtqekfm...@mail.gmail.com
