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 17:28, Jose Carlos Garcia Sogo wrote:
> On Wed, Nov 06, 2002 at 04:47:57PM -0500, Jeff Licquia wrote:
> > 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?
> 
>   Not at all. I don't know which GST or PGI was first, but what GST aims
>  is to provided a tool for configuring the system, whatever distro
>  you're using. And for doing that it uses backends written in perl. What
>  I would like to see is that, at least for Debian, those backends could
>  be developed together (and even integrated with debconf). I use Debian,
>  so my first target is support for Debian. And IMHO having something
>  like GST for Debian (and more for Debian Desktop) is very useful.

I see.  You mentioned "PGI hackers", so I wasn't sure.

Just for future reference: the configlets aren't, strictly speaking,
required for PGI.  The second stage is completely customizable.  Progeny
even provides a second stage with the package that uses base-config and
tasksel in text mode, just like boot-floppies (the standard Debian
installer up to now) does.

So, if you wanted to create a PGI-based install using GST instead of the
configlets, it would be fairly simple to do.  Just install the "pgi"
package on a Debian box and take a gander at /etc/pgi for more
information, or read the documentation included with the package.

>   Yes, I know. I'm a Debian Developer :-)

I noticed the @debian.org; I'm just making sure that everyone on the CC
knows what I'm talking about.

> > 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.
> 
>   I agree with you here. Perhaps for this we should enable those
>  "plugins" also in the basic level. And if the plugin goes with upstream
>  package, people from other distributions will also see that in GST (or
>  they should bitch their distribution makers)

OK.  I'm not necessarily against centralization; I'm just very
practically-minded, and I know that someone, somewhere, will resent
GST's "stranglehold on Debian's independence", or some such, if given a
chance.

>   That's the point! GST are two parts, backends written in perl and a
>  frontend, currently written for GNOME because this started as a project
>  for GNOME. But what I want to do is to extend the use of those
>  backends. If something like a KDE frontend appears, that would be a
>  great news item. And if PGI uses those backends too, even greater (at
>  least for Debian).

Cool.  Is Perl really necessary, or can other language bindings be
developed?  Someone mentioned that XML is used as a communication
standard; if that's so, it shouldn't be too hard to write language
bindings.

>   What you have to understand is that GST is not a proyect developed
>  only for Debian. Is a project that tries to provide a way for
>  configuring the system for a "Joer Random" user who installs Linux and
>  a desktop instead of Windows XP. And probably he will only use that
>  system for browsing the web and writing some docs.
> 
>   But I also think that extending GST with plugins from packages could
>  be nice, but always hiding that under an "Advanced" button.

That's fine; I agree with the general motivation.

Perhaps Debian's GST can use debconf for the "Advanced" button directly;
if GST is sufficiently easy and general, I suspect that most of the
other configuration situations will be too specific to be useful as a
general GST frontend.

Is GST packaged yet?  I can't find it in my apt cache.


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