on Wednesday 18 November 2009 David Werner wrote:
What is still hard to guess and to rexplore is change of packaging like pattern and packagenames. Would be nice to have a kind of browser to work ot interactivly the software list in advance. It should list all patterns and its content in hierarchical manner and maybe take in old software list (of preversion) and make suggestions for a new one.
unfortunately it's not in my hands but I see your point. You can use the autoyast UI to configure your packages and patterns, so a least you dont have to know the names. But I see the problem that a <software> section from one version can fail on another just because someone had the great idea to rename something again.
Another point is to have backuped configuration files which get changed by autoyast-script, -file sections. Maybe more general a kind protocol. of things that have been done. I know of /var/adm/autoinstall/logs etc. One could afterwards more easely compare wheather there appeared new switches which should taken in updated version of configuration. If one does not have it, it requirers one to install at least one time the system with nearly no changes at all. I think this cycle could get eliminated.
for the <files> section we can talk about it but for scripts it's a bit hard for autoyast to see what you've changed in the system. I think you know best what files you touch and you can create a backpup like "/etc/ntp.conf.old" on your own.
One big xml-file is still awful concept, I guess even if one applies rules. I would prefer a split up in many parts configuration and even do somehow by a homegrown solution. I'm not sure whether it possible to simulate the application of rules before. I think xml as an intermdiate format is for automatic parsing is ok.
you can use classes. We did a huge XML config for SAP recently where the main profile was only classes like this: <classes config:type="list"> <class> <class_name>master</class_name> <configuration>scripts.xml</configuration> </class> <class> <class_name>master</class_name> <configuration>ask-hardware.xml</configuration> </class> <class> <class_name>master</class_name> <configuration>ask-mail.xml</configuration> </class> ... and so on ... we used 23 classes files
The DTD files should seperately available to applicant before a first installation of new version opensuse. Fishing them somehow from rpms of distribution is not that nice. I would vote for svn-repository for that.
hm. I dont really see the benefit in putting the rnc files into a separate repository.
The documentation should as datailed as possible. I still
that's always true ;) But it's also always true that the documentation is just a simplified version of the reality ;)
have the feeling that documentation is more by examples and DTDs which one has to watch in than by abstract listing of features.
that's true for some parts of the documentation. If you think that a part of the documentation is not useable or totally outdated, please open a bugreport. -- ciao, Uwe Gansert Uwe Gansert SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Business: http://www.suse.de/~ug -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-autoinstall+help@opensuse.org