Fernando <[EMAIL PROTECTED]> 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