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-18-2011, 08:12 AM
Josselin Mouette
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1298020358.18394.59.camel@meh">http://lists.debian.org/1298020358.18394.59.camel@meh
 
Old 02-18-2011, 08:29 AM
Stefano Zacchiroli
 
Default RFC: bringing back task packages

On Fri, Feb 18, 2011 at 10:39:16AM +0900, 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 ?

More generally, it might have sense to present tasks hierarchically,
with some sort of cut-off thresholds, e.g.: by default you only see
top-level tasks, but you can ask to see more. This is kind of orthogonal
to what you and Pabs ask for blends (in your case the top-level choice
is not really a choice, but only a menu hiding other "top-level"
choices), but both seem to be way of managing the problem of "too many
tasks" presented by Joey.

Cheers.

--
Stefano Zacchiroli -o- PhD in Computer Science PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams
 
Old 02-18-2011, 08:51 AM
Adam Borowski
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110218095105.GA16828@angband.pl">http://lists.debian.org/20110218095105.GA16828@angband.pl
 
Old 02-18-2011, 09:47 AM
Holger Levsen
 
Default 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
 
Old 02-18-2011, 12:49 PM
Andreas Tille
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110218134908.GH9698@an3as.eu">http://lists.debian.org/20110218134908.GH9698@an3as.eu
 
Old 02-19-2011, 03:04 AM
Charles Plessy
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110219040416.GC18279@merveille.plessy.net">http://lists.debian.org/20110219040416.GC18279@merveille.plessy.net
 

Thread Tools




All times are GMT. The time now is 12:13 PM.

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