Re: [gentoo-dev] Antwort: Re: [gentoo-dev] YaST will be GPL [Virus checked]

[John Nilsson]

On Sat, 2004-03-20 at 10:58, Stuart Herbert wrote:
> On Saturday 20 March 2004 00:18, John Nilsson wrote:
> > Could you elaborate on that?
>
> One of Gentoo's strengths is that most packages are installed *without* any
> sort of customisation at all.  If you were to download the tarball, compile
> and install it yourself, what you'd end up with would the same or almost the
> same.
>
> This approach also has the advantage that packaging new versions of packages
> is a very straight-forward piece of work.
>
> Now, if you want to change every package's existing configuration file with
> any new approach, where is this change going to be made?  Some packages may
> adopt it upstream, but not every package will.  So, eventually it'll come
> down to Gentoo to add this support when they package up a new version.  I
> just don't see Gentoo being able to patch each and every tool that has its
> own configuration file.
>
I never ment that Gentoo developers would do some non standard things to
the packages. If the standard is not good enough to convince upstream
developers to change, it is not good enough, period.



> That way seems to be quite a change in direction for what Gentoo actually is.
> http://www.gentoo.org/main/en/about.xml is very clear.  Gentoo is a *meta*
> distribution (their emphasis).
>
> It's also worth pointing out that AIX has been doing this for years.  Having a
> GUI is great, but sooner or later you need to do something that the GUI isn't
> flexible enough to do.
>
> Another way would be to leave the packages alone, and instead have a tool that
> is programmed to write out the config files that each package wants / needs.
> Sounds like Linuxconf, doesn't it?  Need I say anything more?

This is also why I don't trust Linuxconf, webmin, xf86config or what
have you. The configuration logic is part of the tool. The chance of the
tool not being up to date with the packe to configure is greater than
zero.


> > My suggestion was not to replace text-based
> > configuration, just unify the formating of them...
> > I also believe that this is a perfect application for XML. It is still
> > text-based though.
>
> If you're going to create a tool that generates each package's normal config
> file from an XML-driven system, I'd be willing to bet that you can't find an
> XML structure that allows you to do this for all cases.  And the closer you
> get to one, the more complicated it becomes.

The generated file would be a xml-file. This xml-file would be the
package "normal" config file.
The whole point is that the Schema to validate the xml-file would be
developed by the upstream package developers.
This schema would also contain the documentation for the configuration
file. From this Schema a man-page could be generated. Thus config tools
and man-pages would have the same source of information.

> It also sounds like you're pushing a technology that is looking for a
> problem ...

It might be true that I narrowly think XML. I have recently studied it
for a solution to some work related projects.
However I think it is a good solution in any case. One could pick any
syntax imaginable, xml however has the edge of being ready for use
today.

> > Developers create a Schema that a configuration file must validate
> > against.
>
> Which developers?  Gentoo developers, or the upstream developers?

Upstream. Gentoo is a meta distribution as you say.  I would call it "a
proof of concept hack to demonstrate portage" if honest =)
Don't get me wrong I run Gentoo as my only OS on all my home machines, I
love it.
However in another world I would have the portage tree only contain
forks of the packages and then heavily develop the whole system for
consistency. One can dream, right?
 
>
> > > Now for this to be usable, a Schema (or DTD) is developed that
> > their Schema must validate against. This uber Schema is formulated in a
> > way such that a configuration editor, adhering to the standard, can edit
> > any applications configuration in a secure and user friendly way without
> > "plugins" or modification.
>
> What value would this configuration editor actually add?  It's going to have
> to know quite a lot about the permittable combination of options, and their
> side effects, to add much more value than using an existing "configuration
> editor" such as vi, emacs, KWrite, and so on.
>
I'm not talking about a configuration editor. I'm describing a
"protocol" that a configuration editor can implement. The value would be
that all data required to create a valid configuration file would come
with the file not with the editor.
I can imagine someone engineer a clever XSLT technique to solve some
Gentoo specific problems without actually touching the packages...


> Sounds like you'd just end up having to duplicate each packages' existing
> configuration file validation logic into the tool via the XML.  Duplication
> can work if you're in competition - but when you've got two people or groups
> doing exactly the same thing, usually one group ends up giving up.

As stated earlier this system depends on upstream developers to throw
out their current system and implement this. Thus it has to be GOOD
ENOUGH.

> > In a way the Schema from the app is a generalized plugin that kind of
> > "implements" the configuration superclass... (for you OOProgrammers =)
> >
> > -John
>
> I'm not convinced that this effort will be successful, or that it adds
> sufficient value to be worth trying.
> Just a personal opinion,
> Stu

All opinions are important, I don't want to wast my time on a system no
one would use =), how ever i could investigate the matter further and
deeper if it seems promising.

Now this isn't Gentoo specific, but it is a system worth considering in
further "System configuration gui" research.

-John