> From your message I can't exactly tell why we can't have it for
> Squeeze. My personal experience is that I've been using
> CONCURRENCY=makefile since several months now, and I've never run
> into problems.
I know there are bugs in the dependencies, which only affect some
combinations of packages when concurrent booting is enabled (example:
#508289) , and believe the number of users testing with
CONCURRENCY=makefile is so low that it is unlikely that all such bugs
have been found and detected. There is also the issue with booting
too fast exposing race conditions, where the boot just happen to work
now in sequential mode. I ran into issues with X failing to start
when CONCURRENCY=makefile and readahead were both enabled, and never
found time to track down the problem. I suspect the cause is that
some services are not operational when their init.d script is
finished, causing their depending scripts to fail if the boot happen
And I also got the idea that Squeeze will freeze fairly soon, and
given my believe that there are edge cases and race conditions left to
fix, introducing it shortly before freeze seem like a bad idea.
All of this is based on my belief that there are very few people
testing with CONCURRENCY=makefile. If a lot of people are using it
successfully, it is less likely that there are many race conditions
and edge cases left to fix, and enabling it for Squeeze would be a
more safe option.
Working with the boot system tend to make me very careful when
introducing changes, as a wrong upload can render a lot of machines
unable to boot.
> The init.d world has changed quite a bit in recent years and might
> change even more in the next, it is possible that for Squeeze+1
> we'll want to be elsewhere than at CONCURRENCY=makefile.
I am quite sure we will still have init.d scripts around (the LSB
require it), but I also hope we have replaced /sbin/init with an event
based system, pushed most scripts out of rcS.d/ and into rc[2-5].d or
event triggers. It should both solve the broken single user in Debian
and make sure machines boot no matter the type of hardware
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org