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

[Jose Carlos Garcia Sogo <jsogo debian org>]

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.

> 
> >   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.

  Perhaps I have explained, or thinked it more, in the other mail I have
 sent. Of course GST can get things from Debian. What I mean is that I'm
 not sure if it's good for GST that every package can plug there its
 configuration, only from the Debian part. GST is more a tool for users
 who need to configure network, shares, some users (wife, son, ...) and
 perhaps X (every desktop user could need to configure X), not for 
 configuring Apache (for example). Perhaps what could be done is to add an
 "advanced" mode, in which those other configurations tools provided by
 other packages could be showed. If that is done defining a good
 interface, RedHat people can do the same with their packages.

> 
> 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. 

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

> 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.

  But I'm not talking about "every package" and "every mantainer". We're
 talking about a bunch of packages, and some matainers. And what GST
 backends need to know is only how to set things for that package in
 Debian.

> 
> 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.

   Here we go! :)

> 
> 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)

> 
> (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.

  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).

  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.

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

  Yes, please do that.

   Thank you for your time, and I hope we can start to understand
  ourselves on what we're talking about :-)

    Cheers, 

-- 
  Jose Carlos Garcia Sogo
     jsogo@debian.org

PGP signature