Hi!
The work on debconf_select was actually the begining of more work on
partman to make profit of the new cdebconf column alignment feature.
Look at the end for more details. :)
On Sun, Mar 30, 2008 at 06:01:51PM +0200, Frans Pop wrote:
> Suggestion
> Copy the existing function debconf_select() to old_debconf_select() and add
> the following near the top of the new debconf_select for backwards
> compatibility and transition: […]
I would never thought of checking the presence of Choices-C to enable
backward compatibility. I have added exactly what you suggested. :)
> On Sunday 30 March 2008, Jérémy Bobbio wrote:
> > * The deprecated ability to set default values through localised
> > strings have also been removed.
>
> What exactly is the new preseeding? Has that been tested?
I should have tested more before writting that. This situation is
better than I origanally thought: the proposed debconf select actually
allows to be preseeded with: localized strings, internal value and
plugin name (when used with ask_user, and with or without the begining
numbers).
Preseeding with localized strings actually comes for free: Choices is
not mangled anymore, and cdebconf will return the corresponding
Choices-C value automatically.
> What would [1] need to be changed to after this patch is applied?
It could stay as is. But I would change the following:
# If the system has free space you can choose to only partition that space.
-# Note: this must be preseeded with a localized (translated) value.
-#d-i partman-auto/init_automatically_partition \
-# select Guided - use the largest continuous free space
+#d-i partman-auto/init_automatically_partition select biggest_free
# You can choose from any of the predefined partitioning recipes.
-# Note: this must be preseeded with a localized (translated) value.
-d-i partman-auto/choose_recipe \
- select All files in one partition (recommended for new users)
-#d-i partman-auto/choose_recipe \
-# select Separate /home partition
-#d-i partman-auto/choose_recipe \
-# select Separate /home, /usr, /var, and /tmp partitions
+#
+# All files in one partition
+d-i partman-auto/choose_recipe select atomic
+# Separate /home partition
+#d-i partman-auto/choose_recipe select home
+# Separate /home, /usr, /var, and /tmp partitions
+#d-i partman-auto/choose_recipe select multi
I have not tested that last part though, but looking closely at the
code, I don't see a reason that would prevent this to work.
> From what I remember when I looked into this myself, I think Choices-C now
> contains technical codes instead of English strings. If I'm correct these
> codes are not really human readable and are sensitive to change (e.g.
> because they contain sorting codes), and thus not suitable for preseeding.
We could compare the defaul value against the Choices-C value with its
sorting code stripped and correct the preseeding if they match.
That's currently how it works for ask_user's plugin name, it would just
be a matter of generalizing this. If I misread choose_recipe earlier
on, it would also make my proposed preseeding work without a doubt.
* * *
Back to aligned partman screens: attached is a patchset implementing
aligned columns in the active_partition and choose_partition screens of
partman. And a bunch of small fixes and improvements…
I am quite happy to finally be there. :) It's been a while since this
improvement is in every one's mind who ever tried the graphical
installer. But I find myself lacking the "Wow!" effect: it just feels
like it should always have been like that. :)
The patch logs should speak by themselves, but there is at least two
debatable points:
* The removal of valid_visuals.d to use visual.d directly: the former
was meant as a filter for the content of visual.d, but it really
complicated the implementation of aligned columns and seemed pretty
useless to me.
* Loosing right-alignment for the partition numbers (#3) and size
(100 GB).
This last point might be a show-stopper if we think that avoid
regression in the newt frontend should be our priority. The improvement
in the graphical installer outweight this, IMHO, but one might disagree.
I have started to implement what was needed to support right-aligned
columns, actually, until I stumbled against this in Pango's
documentation: "alignment must always be PANGO_TAB_LEFT in the current
implementation." So except someone steps up and find a way to redo
column support in the GTK+ frontend without using PangoTabArray, I feel
that we will need to wait until Pango supports PANGO_TAB_RIGHT.
Of course, we could support right-alignment only in the text and newt
frontend for now, and silently discard the directive when using GTK+…
I'd be glad to get any opinions. :)
Overall stats (without the changelogs):
66 files changed, 234 insertions(+), 271 deletions(-)
Cheers,
--
Jérémy Bobbio .''`.
lunar@debian.org : :Ⓐ : # apt-get install anarchism
`. `'`
`-
Attachment:
partman_align_v1.diff.gz
Description: Binary data
Attachment:
signature.asc
Description: Digital signature