Re: [Setup-tool-hackers] Gnome System Tools + PGI + Progenyhackers + more developers from Debian = working Debian Desktop

[Jeff Licquia <licquia progeny com>]

On Wed, 2002-11-06 at 12:45, Jose Carlos Garcia Sogo wrote:
>   GST uses backends written in Perl. What we're proposing is to develop
>   those backends together among PGI and GST hackers. 

OK.  I take it that you guys are doing a custom second stage to PGI?

>   About the frontends, what you say could also be done. But Debian
>   should only plug tools for Debian specific things (for example apt).
>   GST aims to provide a unified system configuration for every distro,
>   so if each Debian developer can plug a config tool for his package
>   (and that config tool is not provided upstream, so other distros can
>   have it), GST starts to loose their goal.

Well, I can't think of a reason why GST can't grab Debian-specific stuff
as needed (apart from licensing, of course) and integrate them upstream.

In Debian, the package maintainer is king.  If the maintainer wants to
do things a certain way, then generally that's the way things are done. 
It's an awfully strong argument to say that, whenever a Debian
maintainer and GST disagree on how something should work, GST is always
right.  Unfortunately, that's exactly what you're saying with the
"unified tool" idea - unless the maintainer goes through all the work to
convice all the other GST-using platforms to do it his/her way, which is
quite a burden of proof for the maintainer to bear.

I suspect that, in this case, the maintainer would simply tell the GST
people to piss off, and go do his own thing.  This, obviously, breaks
the "unified tool" goal even worse than allowing maintainers to write
their own frontends would.

>   IMHO, the way to go is the following: for example, PGI hackers want to
>   add support for network config (I know that it's yet developed, but
>   it's an example). They write the backend for Debian, and develop a
>   frontend. Both are included in GST. If sometime later RedHat folks
>   want to add support for network configuration in their distro, they
>   only have to extend the backend with those fuctions that are someway
>   different than Debian ones, but the front-end doesn't care about the
>   internal functions, as it talks with an intermediate an well defined
>   API.

This works if people agree on the basic UI, which will be mostly true
for well-established processes like network configuration.

One place where people might not agree on the basic UI might be printer
configuration.  Debian has at least five different print spoolers and
three different driver sets (soon to be four).  Will one UI be able to
cover the needs of all those combinations?  Things become worse when you
consider that the UI might need to change for each printer if you use
one particular spooler (CUPS, which uses PPD files to describe possible
options).  Throw in the possibility of adding the ability to clean print
heads, align print heads, and other housekeeping duties (which will also
be printer-specific), and you've got a major mess on your hands.

So far, I think Debian has resigned itself to using each print spooler's
native UI for setup (which, in some cases, is no more than "vi
/etc/printcap").  My intent to solve this problem in the configlets was
to simply write a configlet that works with one subset (CUPS and
foomatic-supported drivers), and let people who care about other subsets
write their own configlets to handle those cases, or extend mine to
handle them if possible.  Since the configlets are generally parts of
the packages they configure, this can work in ways that GST, as a
centralized solution, cannot.

(FWIW, I'm now leaning more towards a solution based on Progeny's
discover 2, but that's neither here nor there.)

>   Only GNOME part of GST is GNOME-specific. Backends are written in
>   Perl, and you can write other front-ends over them (for text or KDE).
>   Of course, GST and back-ends should be splitted in different packages.

It sounds like GST is a middleware layer, with backends specific to
particular distributions and frontends specific to particular UIs.  Is
it actually possible to write curses frontends to GST?  If so, it sounds
very cool.

It sounds to me like I need to check out GST a bit closer.


_______________________________________________
setup-tool-hackers maillist  -  setup-tool-hackers@ximian.com
http://lists.ximian.com/mailman/listinfo/setup-tool-hackers