[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Those task packages



Philip Charles wrote:
> Been messing about with my list.  These tasks fit onto the first CD.
> Size, including multiboot, 637MB.
> basic-desktop
> laptop
> dialup
> print-server
> unix-server
> spanish
> german
> french
> polish
> russian
> japanese
> korean

I take it there's no chance of getting the desktop task to fit on cd #1?
That's a real shame, because that's a task 50% of installers will want.
Perhaps it needs to be unbloated a bit.

I hope you know that it's possible to include only part of a task on a
CD, and tasksel will only install the available parts, if the task is
selected. One has to be careful which parts are included on the CD
though. If you just insclude, say, menu, on the first CD, then tasksel
will show the desktop task and let people select it, though only menu
will be installed. (This probably needs to be reconsidered).

Since base-desktop contains x-window-system, which depends on
x-window-system-core, which is in the desktop task, I assume that this
is in fact the case, and that users installing from CD #1 will see the
desktop task, and get nothing much besides X (and perhaps not even a
window manager) if they select it.

The ways around this that I can see are:

1. Include at least a working subset of the desktop task on CD #1.
   Probably one of kde or gnome (and we wanted to avoid that decision,
   sigh).
   
2. Hack debian-cd's Packages files to remove items from Task: headers of
   the packages file of CD #1 that are for tasks aside from those you
   listed above. Let people deal with the desktop task being on another CD.
   This has big problems of its own; if the "Task: desktop" header is
   missing for say, x-window-system-code on all cd's, then if the user is
   using enough cd's to see the rest of the desktop task, they will be in
   for a rude suprise when they don't get X. If the Packages file on CD #2
   is a superset of that on CD #1, and so on, and apt merges them in the
   right way, this might be ok.

3. Add markers to the task files saying what packages are very important
   to the task as a whole, and have tasksel refuse to display the task
   unless all such packages are available. Perhaps the cleanest
   solution, but it means a significant untested new chunk of code in
   tasksel.

-- 
see shy jo



Reply to: