Re: [D-I] Supporting 2.6.14 kernels in base-installer
On Mon, Nov 14, 2005 at 08:38:03PM -0800, Steve Langasek wrote:
> On Mon, Nov 14, 2005 at 10:38:41PM +0100, Sven Luther wrote:
> > I still think choice is good, and also what users expect of debian. A sane
> > default, plus the ability to override that in expert mode.
>
> Choice is overrated, and a poor substitute for properly working tools.
> "Which initramfs generator do I need to use so that my system will be
> bootable post-install?" is not a choice that *any* user looks forward to
> making; if a user really has a strong preference for yaird vs.
> initramfs-tools, that option is open to them after the install.
Well, the main point of choice, is that currently none of the two tools are
perfectly bug free and will work in each case. If there is a situation better
supported by one tool over the other, and it happens to not be the one chosen
by us, that user is screwed, as he will have to go into loads of loops to make
it happen. Having both tools on the install media, and having the question
asked to users at expert level ensure only mild disconfort, and will be fully
transparent in normal install track.
The real question here is :
1) what does it cost us.
There are two things that where mentioned as costs. A possible extra 8MB
(less if we can go with perl-base only), on the install media. This i
believe is negligible, as we need to put it in with big enough priority
anyway.
Joeyh is concerned about testing. I personally have doubts that this is a
bad thing, as it means more testing which is good, but i defer to his
greater experience on this.
2) what does it bring us.
Well, apart from the above scenario (the main tool being broken in some
corner case), i still believe it is good to have the choice at least during
the early testing and evaluation period, even if we drop it later for the
release, once the tools maturated, and a choice is made.
To add to that, i personally believe that the yaird approach is the better
approach, and have said so in the past, but initramfs-tools is better for
other reasons, like its upgrade path from 2.4 (of questionable value in d-i
though), and its more generic cover all cases situation, which will lead to
over-bloated ramdisks if the use cases (lvm, raid, evms, nfs, whatever)
increase.
> Too often, Debian developers (and Open Source folks in general) give users
> "choices" in lieu of making sound technical decisions or fixing bugs. I'll
> take "install this; it works, and when it doesn't, the bugs will get fixed"
> any day over "well, you can have mediocre.py, or you can have mediocre.pl;
> if one doesn't work, use the other one". In the case of initramfs
> generators in the installer, giving users "choice" instead of just fixing
> bugs means pushing the load on the installer team for testing a greater
> number of code paths, and on the translators for debconf templates that no
> one should ever need.
Nope, it is more than a technical difference in language used, it is a
different design goal between both.
> It's ok if both of the available alternatives are currently buggy and we
> don't yet know which one represents the correct technical decision; or if
> the correct decision varies from architecture to architecture. None of
> these are reasons to not make the decision -- we just can't make it /yet/.
And making the choice possible in d-i right now will allow us easier testing
and thus ease making a decision later. I still don't get why we can't propose
a choice in expert mode, what is expert mode good for then ?
> Incidentally, I'm pretty sure that regardless of which initramfs generator
> d-i favors, the dependencies on the linux-image packages should be switched
> around to put initramfs-tools first so that we have an automatic upgrade
> path for sarge systems using 2.4 kernels. (Obviously, d-i can install
> whichever is better from an installer POV instead.)
Indeed this was the plan, well this or another solution, but at the time of
the choice initramfs-tools was both FTBFS and uninstallable, and then later
Maximilien was unavailable for as week or so, and i didn't think it would be
good to switch while he was away. I still think yaird is the superior method,
but its lack of 2.4 upgrade path is a bother. That said initramfs-tools is
currently broken on alpha, as you well know.
Now, the easiest way is to depend on both, and have the ramdisk magic in k-p
do the right thing.
Friendly,
Sven Luther
Reply to: