sarge, console-tools, debconf or not
On Mon, Jul 22, 2002 at 03:43:55PM +0400, Wartan Hachaturow wrote:
> On Mon, Jul 22, 2002 at 01:13:54PM +0200, Alastair McKinstry wrote:
>
> > So do you have any plans about what to do for console tools in the next
> > Debian release? Do you need help ?
>
> Actually, I've asked people at debian-devel for the things they want
> in console-tools-v2. Short answer is: Nobody cares.
Or they are just happy with the current way it's done :)
> So, I'm feeling free to implement what I like ;)
> The basic idea is as follows:
>
> 1. Split console-data on multiple packages.
>
> That is, each package would contain keymaps.list (and, possibly,
> fonts.list), describing included keymaps in a way similar to
> Packages.gz.
> This list would be scanned upon the build, and the packages like
> console-data-cyrillic, console-data-ethiopic, etc. would be
> created.
>
> 2. Throw away or minimize debconf usage.
>
> As you may see, current console-common code is a nightmare and too
> tightly integrated with debconf. That leads to numerous bugs (due
> to broken databases at some people's stations, etc., etc.).
> My idea is to throw away debconf, and implement something like
> default keymap for each console-data package, and show people a
> debconf note on what to run to change a keymap (a special utility
> like consoletoolsconfig could be written for that matter).
> For those that really like to have debconf for the
> I-want-to-have-my-cluster-machines-all-the-same purpose, there's an
> idea to implement something like make-kpkg -- people would build
> their own, custom console packages, and install them wherever they
> want -- that system can also be used while building "distro"
> packages.
>
> These are two major ideas. Of course, that would lead to a complete rewrite
> of the current console configuration subsystem -- but that's A Good Thing
> (tm), imo ;)
I completely agree with the 1st point, but in a world where all Debian
packages are moving towards debconf, the 2nd really looks like a step
backwards. Despite the problems caused when building the debconf script,
I got a number of people happy with the thing. And if we have multiple ways
of handling configuration, we just shift the nightmare to people writing
installers (hence my CC to debian-boot list and FAI maintainer).
My analysis of why it is a nightmare is quite related with the fact it's too
tightly integrated with debconf: I started to write the code on an ad-hoc
basis - some sort of RAD - and progressively started to abstract things.
What I'd have liked to see is this abstraction process turn into some sort
of hierarchical-select debconf widget. That is, effectively completely
de-coupling the handling of the tree-like classification from the console
stuff proper, and in the end having some sort of "Type: hierarchical-select"
available in debconf.
Unfortunately, my attempts to convince the debconf maintainer we should go
this way were vain - I do not recall reading a word of encouragement from
him, nor any suggestion as to how to do it another way. Yet I don't see how
it could get done properly within debconf otherwise.
What I'd suggest would be first to check with Joey Hess his opinions on the
subject - I know he would be of valuable help if convinced - before going
another way.
Opinions, anyone ?
--
Yann Dirson <ydirson@altern.org> | Why make M$-Bill richer & richer ?
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
Pro: <yann.dirson@fr.alcove.com> | Freedom, Power, Stability, Gratuity
http://ydirson.free.fr/ | Check <http://www.debian.org/>
--
To UNSUBSCRIBE, email to debian-boot-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: