On Sun, 17 Mar 2002, Joey Hess wrote: > 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.
According to my figures, desktop, dialup, laptop and unix-server take up 323238 MB. Some of these tasks will have packages in common so the space taken will be slighty less. We have ~270000 KB available on the first CD. I can but try this and see what happens. > 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). This problem is basicly solved. The packages of each task are grouped together and are put on the CD as a block. However, the task packages can split when the first CD has been filled before all the packages of a task have been placed. In my case chinese -s is split. > 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. > > According to the tasksel README, I have not done a install from a CD. "On startup, the tasksel program will read /var/lib/dpkg/available to identify task packages (matching "task-*")." My understanding is that if no package mentions a task, then that task is not presented. > 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). I test the desktop, dialup, laptop and unix-server option later today and see what how much needs to be cut from desktop. > > 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. A meta-package (yuck) in desktop containing the basic-desktop packages? Then desktop could be removed from the Task: field leaving only basic-desktop. There may be other tasks interrelated in the same way. Will check. > > 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. The only time this will happen is when the build is moving from the first CD to the second. The way I am doing this is, cat task.list | while read LINE; do \ apt-cache dumpavail | grep-dctrl -F Task $LINE -n -s Package;done > \ ./tasks/task-woody where task.list lists the tasks in the order they are to go onto the CDs. The trick is not to sort task-woody so that each package is put on the CDs in the prescribed order. Phil. -- Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand +64 3 488 2818 Fax +64 3 488 2875 Mobile 025 267 9420 [EMAIL PROTECTED] - preferred. [EMAIL PROTECTED] I sell GNU/Linux & GNU/Hurd CDs. See http://www.copyleft.co.nz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]