Re: Partition tools (Re: debian-installer status -- 2002-07-29)

[Jim Lynch <jwl@debian.org>]

On Mon, 29 Jul 2002 18:46:41 -0400
Matt Zimmerman <mdz@debian.org> wrote:

> On Tue, Jul 30, 2002 at 12:09:08AM +0200, Eduard Bloch wrote:
> 
> > #include <hallo.h>
> > Matt Zimmerman wrote on Mon Jul 29, 2002 um 09:00:42AM:
> > 
> > > What is the basis for your objection?  Are you going to try to stop someone
> > > else from doing this development?
> > 
> > Pretty simple. The same reason as for not having XFS in the default
> > kernel:
> > 
> >  - development stage

Yes, but xfs is getting cleaner as time goes by. Development thereof
seems to be in capable hands, whose owners have fairly deep understanding
of the kernel.

> >  - not in the kernel

Reasons for things not being in the kernel are not always technical.
Will you not want grep because it is not in the kernel? (OK, sorry, not
the greatest example; point being there are developments that should be
looked at; some of those are modules developed in periphery. In this
way, changes can be prepared for sooner.)

> >  - changes lots of stuff in the kernel

Sheesh... OF COURSE it does: it is a kernel module. How will you 
get an external module in without doing so? What does either do
other than add themselves to the kernel as a module? Be specific.

OK, maybe you're right WRT the -default- debian kernel.

> >  - not stable or has other nasty bugs

Specifics. No fud, please. Please include references and examples.

> >  - future stable version breaks things

Future fud. How would you know? All you can do is guess.

The only thing I can grant you here, is we've all seen that happen in the past.

> > I know that you like EVMS, and I do too, but it's still beta-ware. You may
> > argue that it will be stable to the time when Sarge is ready - but we do
> > also release with 2.2.x as default 1.5years after 2.4 release.
> 
> I am in complete agreement that we would not want to include EVMS, XFS or
> similar in our default kernel unless (or until) they are part of the
> official kernel.

Please find the reason for EVMS not being incorporated. Also, is LVM not
going to be part of the kernel in the future? I'm not totally sure about
this part, but I thought I had read that Linus wants LVM out; note that
there have been fairly nasty core-level bugs in LVM in the recent past
(the last one I knew of involved main stack overflow causing big
filesystem problems: I recall patching to kill that particular bug on my
personal machine).

>From what I know about LVM and EVMS, the latter's development is being 
carried out by people who understand the kernel; the former, not so 
much: some of the LVM developers had a falling out with others; the
group who understood kernel issues were harping on technical issues.
They got kicked off the mailing list for doing so. Hence, they are left
with people who don't understand the kernel quite as much.

I propose that we measure the stability of each, and make a decision 
based on stability, rather than whether or not a certain module passed
political muster to be included in the kernel.

I further propose that we take looks at these technologies more often,
looking at the development status and trying things out.

In addition, let's get more people working on debian-installer. Having
built it once, I find that process easier than b-f (having also built
-that- once as well). Now I need better floppies, so I can try it :)

> However, I am willing to do some work to support EVMS in d-i, and to provide
> EVMS-enabled installation media for those who are interested in trying it.

That's definitely more like it... there are many who would want to try such
things.

It would also be good to work toward standardizing naming of volumes (err,
allowing such naming of volumes to happen in the installer), and allowing
the creation of EVMS, LVM, LVM2 (worth a look!) volumes. Current installer
does not allow these things; I think work in these areas should begin as
quickly as possible. Should the kernel VFS be extended to allow things 
along these lines?

> If I can use this experience to improve volume management support in d-i,
> then I would hope that my contributions would be welcome.

As far as I'm concerned, such contributions would be very welcome.

>  - mdz

-Jim

P.S., I just noticed I'm replying to a 3-week-old message; hope my
comments are still appropriate.