Re: Buts about partman [LONG]
On Thu, Jul 26, 2007 at 01:35:19AM +0300, Anton Zinoviev wrote:
> In the main screen of partman, it uses spaces in order to align
> columns. Obviously this doesn't work in g-i since there the font is
> proportional. Partman also trunkates fields when necessary, this
> shouldn't be done in g-i.
>
> I have no idea how debconf works, but here is what parman can do
> easily in order to improve the situation.
>
> (1) db_capb align
>
> If debconf answers that it supports 'align' capability, then partman
> is going to use the Select template in a different way.
>
> (2) The first "choice" in 'align' mode is not a real choice, but a
> line of titles of the columns that follow. The names are
> separated by a special delimiter (such as '$$')
>
> (3) The next choices are the real choices. They also use this
> delimiter between fields.
Two things. Firstly, I think column support like this is definitely
useful and I'd like to see it done (though we could bikeshed about the
separator details; I'd prefer something we can set up to guaranteeably
avoid ambiguity).
Secondly, partman also uses trailing spaces to disambiguate otherwise
identical-looking lines so that they're different choices in debconf.
This has always been recognised as a hack. The root problem here is that
partman uses complex constructed strings as the choices; this makes
preseeding very difficult in places as well. Obviously the English
choices should largely remain as they are now, but debconf now supports
"Choices-C" which can be used for machine-readable choices. For example,
the choice for a line in the partition tree could just be "/dev/sda1"
(or /var/lib/partman/devices/=dev=sda//0-8589934591, which might be
simpler internally) and the English choice (Choices as opposed to
Choices-C) could be the visual representation as calculated by partman.
I tried to do this myself a little while ago, but failed. I think it
should be possible, though, since partman already passes tab-separated
key/option pairs to debconf_select.
> 3. Issues with the boot partitions in partman-auto (Yaboot, Palo, etc.)
> -----------------------------------------------------------------------
>
> Some boot loaders require a special partition. Problems:
>
> 1. partman-auto creates a new partition even if there is already one;
>
> 2. partman-auto doesn't know anything about the specific requirements
> of this partition (size, placement on the disk)
>
> 3. We have too many architecture-specific recipes (IMO unmaintainable)
> and for some of them it is not even obvious why they exist.
>
> Solution: Do not create new architecture-specific recipes. Instead the
> boot loaders should install a plugin in partman-auto which causes it
> to create the special partition first and only then to perform the
> recipe. I think I am going to describe a method somewhere, maybe
> partman-doc.sgml, but I am not going to do any implementation since
> this is not a i386 problem. (Well, I could test a solution on i386
> too, but I think don't have free time for this.)
I'd be happy with this; the architecture-specific recipes are a mess.
I'd propose a slight variation on this, though. How about, instead of a
plugin, we allow specifiers like $yaboot{ }, and invent some way for
bootloader installer packages to enable this? That way, all the recipe
data could live in the main recipe files, and just be disabled if it's
not needed.
I don't know if this addresses your first point, though, as partman-auto
has no way to reuse existing partitions at the moment (which BTW I think
it needs to learn about eventually). Maybe your plugin idea would be
easier to implement.
--
Colin Watson [cjwatson@debian.org]
Reply to: