LSB-compliant init-scripts as release goal.

[Petter Reinholdtsen]

[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