Re: Those task packages
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
philipc@copyleft.co.nz - preferred. philipc@debian.org
I sell GNU/Linux & GNU/Hurd CDs. See http://www.copyleft.co.nz
Reply to: