[Stefano Zacchiroli] > 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 too quickly. 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 connected. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2fl6330b0f7....@login1.uio.no
