Re: Status for reiser support in d-i
On Tue, 2003-08-26 at 17:23, Richard Hirst wrote:
> On Tue, Aug 26, 2003 at 04:57:36PM +0400, Yury Umanets wrote:
> > On Tue, 2003-08-26 at 16:34, Richard Hirst wrote:
> > > On Tue, Aug 26, 2003 at 01:39:05PM +0400, Yury Umanets wrote:
> > > > On Tue, 2003-08-26 at 13:22, Petter Reinholdtsen wrote:
> > > > > [Yury Umanets]
> > > > > > But when I said, about improving parted interface, I meant, that
> > > > > > somebody should write a patch exactly to making parted to use
> > > > > > ncurses or something like this. I've not meant to write another
> > > > > > front end. Actually there is one called qtparted.
> > > > >
> > > > > Area you aware of nparted,
> > > > > <URL:http://www.laespiral.org/proyectos/nparted/>?
> > > > No, thanks,
> > > > >
> > > > > It seem to be dead upstream, but was a nice start. :)
> > >
> > > There is also cparted <ftp://ftp.parisc-linux.org/src/cparted/> which I
> > > started some time ago. It looks similar to cfdisk, but handles msdos
> > > and efi partition tables via libparted.
> > >
> > > One problem with it is that as you make changes via the user interface,
> > > they are committed to disk directly. You don't have an oppertunity to
> > > abort after playing with your partition table, as the disk is already
> > > modified. That seems to be the way parted works, and is not very suited
> > > to an installer. Someone once said it was possible to make libparted
> > > work with an in-memory image of a partition table, and avoid commiting
> > > to disk until you were happy with all your changes. Havn't investigated
> > > that though, and I'm not sure how it would work w.r.t. the parted
> > > approach of examining a partition content to decide what type it was.
> >
> > What about filesystems? Suppose you have created partition. And suppose
> > also, that you're going to create filesystem on it. But filesystem
> > cannot be created without partition being initialized first and
> > filesystem cannot be created in memory.
>
> I agree, that is a problem. One approach would be to have a front end
> that used libparted to get the existing partition configuration, and
> then modified that data internally based on user interaction. Once the
> user was happy, the frontend could use libparted to implement whatever
> partition scheme the user finally settled on (including creating
> filesystems).
Hm... Looks sane as for me.
> I don't like the idea though; sounds like you would be
> reimplementing parts of parted in the frontend to manage the partition
> data while the user was interacting with it.
> Hence you really do want
> to use libparted to manipulate the partition table, but you don't want
> it to commit changes to disk until you say so.
I guess, parted does this in maner like you've just described. But
parted does not do like you described according to filesystems. It
creates them at user's request without any delay. But I'm probably
wrong.
> I guess you delay making
> filesystems until after the point where you commit to disk. Then you
> end up with libparted keeping track of the proposed partition layout,
> and the frontend keeping track of the proposed filesystem types, which
> is also a little ugly.
Actually redhat installer does something like this. And it uses
libparted though :)
Regards.
Reply to: