Re: Offer of help
Fernando <alegre@saturn.superlink.net> writes:
> > What exactly should the templates be for? Configuration?
>
> Yes. The idea is that all configuration files which need system-specific
> data be generated from templates which hold the non-specific part and
> from specific data residing in a database.
>
> > Who should ever lern the syntax or correct scripts if something is wrong?
>
> See below.
>
> > What happens if you parser doesn't work? Can you still install
> > packages?
>
> If a configuration file is not properly generated the package will install
> but it may not work as intended. In that case, the config file will have to
> be manually corrected. In this respect, nothing changes essentially from
> the current situation.
Packages should be able to install without any question asked. Default
config files must be provided as well as default config databases.
> > Can templates be localised? Do you get localised help to templates?
>
> Yes. Templates in different languages can be provided if it is necessary.
> The most important part is providing help/description of variables in the
> database in local languages. I think this can be accomplished in one of
> two ways:
>
> 1) A multilingual database is provided:
> Name: variable1
> Desc: Default description in English
> Desc_es: .... (spanish)
> Desc_fr: .... (french)
> Desc_de: .... (german)
> Then the user interface chooses the Desc_xx: field to be used according to
> user preferences and availability. (I did not implement a user interface.)
Which brings to my mind that you need several other fields:
Default, SystemDefault, UserDefault, Level, Arch, Type.
Esspecially the type is important, otherwise any GUI to edit the
database won't know what to ask for.
>...
> > I can't see any benefits over my proposal, which probably covers your
> > ideas and much more. My config scripts would be valid bash scripts
> > with only a few limitations to allow for better parsing.
>
> Any system has advantages and disadvantages. I am not going to get into
> a "my system is better than yours" flamewar. I did look at your proposal and
> found it interesting. I also looked at Wichert's proposal and most others
> that have appeared in this list.
Sorry, i didn't want to start a flamewar.
I also looked at all proposals I could find and tried to merge all
good points together and leave out the bad once. I hope I succeded.
> Regarding your proposal, I think it is mostly orthogonal with mine. They
> overlap very little. The kernel-config style system is a good way to gather
> all answers from the user at install time and populate the database. It deals
The kernel-config style is just for frontends, a lot of the proposal
also describes the backend, which would collide with your
approach. Your example looked very complicated, the qvwm example you
did looks a lot nicer. But I especially miss default values and types
of questions.
>...
> > Also you will get problems when people change the config files
> > directly instead of using the database. Those inconsistency give the
> > users hell on earth. You eigther can't use the database at all any
> > longer, because on every run it will destroy all your changes or you
> > can't use it, because it won't work on user modified configfiles.
>
> Any one-way database based system has this limitation. That is why I proposed
> the inclusion of parsers two years ago and that is why I still hope to get to
> that part some day. But a one-way system can still have advantages for many
> users.
And thats the problem. Thats what realy kills you when using SuSe and
yast as a debian user. Debian should handle it smarter.
>...
MfG,
Goswin
Reply to: