Re: Partman and graphical installer (was: Buts about partman [LONG])

[Anton Zinoviev <anton@lml.bas.bg>]

On Thu, Jul 26, 2007 at 03:14:41AM +0200, Jйrйmy Bobbio wrote:
> 
> >   (4) However not all lines will use these delimiters.  Such lines
> >       should not be affected by resizing the columns.
> 
> That is going to be a lot trickier to implement in GTK+, AFAIK.
> Although, really easy in the web frontend. :)

It is possible that it is very difficult fix (4) in partman.  Or maybe
not, I don't know.

Currently the format of the partition lines depends of the type of the
partition tables.  The partition table on i386 has primary and logical
partitions, on the other hand almost all non-i386 partition tables
have no such notion.  On macintoshes the partition table has partition
labels, on i386 there is no such notion.

I suppose this will be OK if all disks on the system have the same
partition tables but what should we do if one of the disks has msdos
partition table and the other is mac?  Things become even more
complicated if we take into account LVM, Raid and encrypted volumes.

> My initial thoughts about implementing a graphical partitioner was
> to use a custom debconf question type.  As, IMHO, string manipulation in C
> should be avoided whenever its possible, I would prefer partman to feed
> the plugin values in the easiest format for the later.

On the other hand partman is already very slow...:)

Each of the plugins of partman provides the core of partman with
information that can be encoded in a way similar to what I described.
This is so to say the protocol between the plugins and the core and
can not be changed.  If you need something different, the information
has to be converted either by the core of partman or by the frontend.

What about a code like the following?

The variable 'choice' is supposed to has a value like this (each field
is terminated by '\t' and '\b' marks the special fields):

FIELD1\tFIELD2\t\blevel:N\tFIELD3\t\bsize:N\tFIELD4\tFIELD5\t

char *p, *q, *r;
int n, m;
char *fields[MAXFIELDS];

n = 0;
p = strdup(choice);
while (*p != '\0' && strchr(p, '\t') && n < MAXFIELDS) {
	if (2 == sscanf(p, "\blevel:%i\t%as", &m, &q)) {
		tag_level = m;
		free(p);
		p = q;
		continue;
	}
	if (q) free(q);
	if (2 == sscanf(p, "\bsize:%i\t%as", &m, &q)) {
		tag_size = m;
		free(p)
		p = q;
		continue;
	}
	if (q) free(q);
	if (*p != '\b') {
		m = sscanf(p, "%a[^\t]\t%as", &q, &r);
		assert((m == 2) && q && r);
		fields[n] = q;
		n++;
		free(p);
		p = r;
		continue;
	}
	{
		# unknown tag, skip it
		m = sscanf(p, "\t%[^\t]%as", &q, &r);
		assert((m == 2) && q && r);
		free(q);
		free(p);
		p = r;
	}
}
free(p);

> One real question though: getting "align" to work in partman might be
> done quickier than what I can imagine right now; should we switch to it
> first before trying to get even better?

Yes, ofcourse.  Do the simpler things first, then the more complex.

On Thu, Jul 26, 2007 at 04:11:10PM +0200, Jérémy Bobbio wrote:
> 
> I meant having a dedicated question type specific to the partioning
> stage, maybe covering more questions at once than how it is currently
> done.

Each of the plugins of partman is allowed to modify almost every
question.  This means the set of questions is standartized and fixed.
Which questions do you want to cover at once?

Anton Zinoviev