Re: task-* problem
On 27 Jul 2000, Philip Hands wrote:
> Philip Charles <email@example.com> writes:
> Presumably, all that packages that make up those tasks failed to fit
> on CD#1, so there's not much point putting the task on #1 and taunting
> the people that have got single CDs.
> > When I rebuilt the trees with only export NONUS switched on
> > everything went well.
> That's because you've freed up some room on #1 by not including
export non-US was switched _on_ and non-US was included in the second
set. The task-* packages were all on the first CD on the second set.
However, when FORCENONUSONCD1 was on for the first set the task-* packages
were scattered as I suspect were others as well. But I have not checked
> The only worrying thing is that you say they ended up on CD#3 --- how
> non-deterministic is this? Are we likely to see a mass migration of
> task packages from CD#1 just because some package that's on there
> grows by a few KB as the result of a last minute fix?
Earlier in the month I built trees which only put the nominated packages
and their dependencies etc on the first CD. These were the results,
Main & contib 597 MB
Main, contrib & non-US 597 MB (378 KB extra)
Main, contrib, non-US & non-free 666 MB
(This was done by removing popularity-contest.)
so as you can see there is room for non-US even if all of non-US was
included on CD1 (41.7 MB including non-US-non-free). Only the packages
nominated by popularity-contest would be shunted to later CDs.
My concern is that is this is happening to task-* packages what is
happening to the others? I suspect that the problem lies in
tasks/Debian-potato. Where is Debian_potato_nonUS? I can find no
reference to it in cvs which I updated earlier today.
Philip Charles; 39a Paterson St., Abbotsford, New Zealand; +64 3 4882818
Mobile 025 267 9420. I sell GNU/Linux CDs. See http://www.copyleft.co.nz