[Gustavo Franco] > In pratical terms, insserv won't be added in none of our tasks, so > the user, admin, whatever will need to install it after installing > Etch. Better than nothing, but not that better than we've now. > > The update-rc.d is a issue right, but you answer below why we should > at least try this even without a new update-rc.d.
Yes, it is unlikely that insserv will be in any of the tasks for etch. Besides, the package is not ready for production use, so someone need to improve it to make work out of the box as a replacement for sysv-rc. Until that patch appears, it is no use to install insserv by default. I believe we should focus on getting the dependency info into etch to detect boot sequence errors, and fix those errors in time for etch. Then the brave can try parallel booting if they want to, and we can fix the remaining problems and get parallel booting enabled by default for etch+1. > I really disagree with your last point. This "slowly" approach is > what makes us (almost) totally non release focused. If we've a great > work being done and can make our release in 4, 5 months why wait > (and add stuff slowly) 22, 23 months (Etch+1) ? If nobody steps in > to really focus on release and its details you will be writing the > same thing for somebody else in 17, 18 months. Take note. Well, my "slow" approach is based on the fact that I have talked about adding dependency information and enabling parallel booting for a year already, and it still isn't implemented all over. I do not believe anyone will be able to make it happen in the few days left until the base system freezes. I hope we can have 80%-90% covered in time for the release of Etch, but doubt we will be finished in that time. There are enough issues to fix before the Etch release, and I do not want to drag the release teams focus away from these. Getting a lintian warning for missing init.d dependency info will most likely increase the adaption speed, but there are still hundreds of scripts remaining. > The "hotspots". Well, there's the discarded "sh->bash" thing, "depmod" > already implemented and what we've more that will improve the boot > times much more than parallelization ? Maybe i missed something, but > these two cited won't. I was not aware that "sh->dash" was discarded. Or do you mean for etch? I agree that it is too late to change it for etch. I must admit that I still have hopes in the preloading, as there are several periods during the boot with no IO traffic at all. I know Carlos initial testing showed no speedup at all, but other distributions are claiming a significant speedup on machines with enough memory, so I still hope it will have effect also on Debian. I also believe script rewrites to use internal functions and telling the kernel and scripts to print less messages will have an impact, but it is hard to tell how much. > Exactly why i mentioned one release goal: SELinux support, that i > think won't make the release so we could ask for a replacement. Well, it does no harm to ask. But when we ask the release team, we will be asked how much of the release goal is already fixed, and how much it will slow down the release process. Do we have clear answers to that question? The list of init.d scripts on Carlos' web page only include the desktop task. There are heaps of scripts outside that task. The insserver package contain quite a few override files, but that is not the complete list of init.d scripts either. > Closing, i can't do all this by myself so if you (Petter) and Carlos > don't want to go this way, i'll move on. I have nothing against asking to get LSB headers listed as a release goal, but have doubts how realistic it is to complete it in time for the release of etch. The only way that could happen, is if several people start focusing on it, and working to make it. I do not have time to work on it before base freezes 2006-08-07, and Carlos have other tasks to complete in that time as well. Who are willing to work focused on finding and fixing all remaining init.d scripts in base before base freezes? Some of the reported bugs are more than 300 days old and still not fixed. Who got time to do the same for the remaining scripts before the rest freezes in October? Friendly, -- Petter Reinholdtsen _______________________________________________ initscripts-ng-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel
