[yast-devel] YCP-killer and YCP data files
Hi all, as you know we are working on a "YCP-killer" project, which should translate all YCP files to ruby and then get rid of our specific YCP language. I found a problem related to reading data YCP files. The problem is that some modules have data in YCP files which are read at runtime via these SCR calls: SCR::Read(.target.yast2, "foo.ycp") SCR::Read(.target.ycp, "bar.ycp") We can convert that YCP files to ruby with the converter but the loading mechanism will not not work. And keeping the data files in YCP format is also not an option. There are basically two possibilities: - convert the YCP files to a different format (plain text, YML, XML...) - modify the YCP files so that they can be used as an include file (includes are converted to ruby files so there is no change needed after the conversion) Which solution is better depends on the data in the file, some non-structured data could be simply converted to a plain text file, converting structured data is usually more complex. The second solution is easier for structured data as the file itself can be more or less left untouched, only the loading mechanism needs to be changed to an include statement. The disadvantage of the second solution is that the data is loaded persistently to memory (as it actually becomes code) so for large data files it might not be a good idea. As a proof of concept I adapted two YCP modules and changed the data files to includes, see these pull requests: https://github.com/yast/yast-ntp-client/pull/5/files https://github.com/yast/yast-mouse/pull/2/files The mouse module is little bit tricky as the database contains translations. And they need to be translated dynamically to reflect possible language changes during installation proposal, therefore I added a wrapper function which always returns a fresh instance of the data with the current translations. Conslusion: If you have some spare time and want to help us with the ruby translation you can start removing the YCP data files. You can look at the pull requests above for a hint how to do that. Or just ask here or on the IRC. Thank you! -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Hi, (sorry for top-posting) Unfortunately, reading is not the only operation with the data - YaST also writes them quite extensively. I don't really know what exactly the problem (internally) is, anyway, I have one suggstion: Does reading/writing of the AutoYaST profiles, installation workflow definition and similar files work? If it does, I don't see any reason not to use this YaST-specific XML. It can hold any YCP structures and also the conversion of existing data should be rather simple. Would this suggestion help? Jiri On 04/25/2013 12:18 PM, Ladislav Slezak wrote:
Hi all,
as you know we are working on a "YCP-killer" project, which should translate all YCP files to ruby and then get rid of our specific YCP language.
I found a problem related to reading data YCP files.
The problem is that some modules have data in YCP files which are read at runtime via these SCR calls:
SCR::Read(.target.yast2, "foo.ycp") SCR::Read(.target.ycp, "bar.ycp")
We can convert that YCP files to ruby with the converter but the loading mechanism will not not work.
And keeping the data files in YCP format is also not an option.
There are basically two possibilities:
- convert the YCP files to a different format (plain text, YML, XML...)
- modify the YCP files so that they can be used as an include file (includes are converted to ruby files so there is no change needed after the conversion)
Which solution is better depends on the data in the file, some non-structured data could be simply converted to a plain text file, converting structured data is usually more complex.
The second solution is easier for structured data as the file itself can be more or less left untouched, only the loading mechanism needs to be changed to an include statement.
The disadvantage of the second solution is that the data is loaded persistently to memory (as it actually becomes code) so for large data files it might not be a good idea.
As a proof of concept I adapted two YCP modules and changed the data files to includes, see these pull requests:
https://github.com/yast/yast-ntp-client/pull/5/files https://github.com/yast/yast-mouse/pull/2/files
The mouse module is little bit tricky as the database contains translations. And they need to be translated dynamically to reflect possible language changes during installation proposal, therefore I added a wrapper function which always returns a fresh instance of the data with the current translations.
Conslusion:
If you have some spare time and want to help us with the ruby translation you can start removing the YCP data files.
You can look at the pull requests above for a hint how to do that. Or just ask here or on the IRC.
Thank you!
--
Best Regards
Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/
-- Regards, Jiri Srain Project Manager --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.com Lihovarska 1060/12 tel: +420 284 084 659 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.com -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 25.4.2013 12:40, Jiri Srain napsal(a):
Hi,
(sorry for top-posting)
Unfortunately, reading is not the only operation with the data - YaST also writes them quite extensively.
I don't really know what exactly the problem (internally) is, anyway, I have one suggstion:
Does reading/writing of the AutoYaST profiles, installation workflow definition and similar files work?
Yes, that should work the same way after conversion to ruby, the agents/libraries will be used.
If it does, I don't see any reason not to use this YaST-specific XML. It can hold any YCP structures and also the conversion of existing data should be rather simple.
Would this suggestion help?
Yes, that's a good idea. Thanks! -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 25.4.2013 12:51, Ladislav Slezak napsal(a):
Yes, that should work the same way after conversion to ruby, the agents/libraries will be used.
Ooops, should be "the _same_ agents/libraries will be used". -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, Apr 25, Jiri Srain wrote:
Hi,
(sorry for top-posting)
Unfortunately, reading is not the only operation with the data - YaST also writes them quite extensively.
I don't really know what exactly the problem (internally) is, anyway, I have one suggstion:
Does reading/writing of the AutoYaST profiles, installation workflow definition and similar files work?
If it does, I don't see any reason not to use this YaST-specific XML. It can hold any YCP structures and also the conversion of existing data should be rather simple.
BTW: AutoYaST itself is also using writing and reading ycp file (e.g. /var/adm/autoinstall/cache/autoinst.ycp) and does not only use xml data. Tschuess, Thomas Fehr -- Thomas Fehr, SuSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Tel: +49-911-74053-0, Fax: +49-911-74053-482, Email: fehr@suse.de GPG public key available. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, 25 Apr 2013 13:21:29 +0200 Thomas Fehr <fehr@suse.de> wrote:
On Thu, Apr 25, Jiri Srain wrote:
Hi,
(sorry for top-posting)
Unfortunately, reading is not the only operation with the data - YaST also writes them quite extensively.
I don't really know what exactly the problem (internally) is, anyway, I have one suggstion:
Does reading/writing of the AutoYaST profiles, installation workflow definition and similar files work?
If it does, I don't see any reason not to use this YaST-specific XML. It can hold any YCP structures and also the conversion of existing data should be rather simple.
BTW: AutoYaST itself is also using writing and reading ycp file (e.g. /var/adm/autoinstall/cache/autoinst.ycp) and does not only use xml data.
Tschuess, Thomas Fehr
Well, from my point of view we have here two cases. The first one is pure data, that is just read. In such case I think we should consider a well known common mechanism to serialize/deserialize data to file like XML, YaML or JSON. The second case is more interesting. It is ycp that do something, so in fact it is code that write code. In such case we can use serialization of code to XML, but I think it will be more useful to write such code directly in ruby ( or perl or whatever ). But the second case sounds wrong for me, as it allows hard to debug bugs, and we should avoid it as much as possible. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 04/25/2013 01:30 PM, Josef Reidinger wrote:
On Thu, 25 Apr 2013 13:21:29 +0200 Thomas Fehr <fehr@suse.de> wrote:
On Thu, Apr 25, Jiri Srain wrote:
Hi,
(sorry for top-posting)
Unfortunately, reading is not the only operation with the data - YaST also writes them quite extensively.
I don't really know what exactly the problem (internally) is, anyway, I have one suggstion:
Does reading/writing of the AutoYaST profiles, installation workflow definition and similar files work?
If it does, I don't see any reason not to use this YaST-specific XML. It can hold any YCP structures and also the conversion of existing data should be rather simple.
BTW: AutoYaST itself is also using writing and reading ycp file (e.g. /var/adm/autoinstall/cache/autoinst.ycp) and does not only use xml data.
Tschuess, Thomas Fehr
Well, from my point of view we have here two cases. The first one is pure data, that is just read. In such case I think we should consider a well known common mechanism to serialize/deserialize data to file like XML, YaML or JSON. The second case is more interesting. It is ycp that do something, so in fact it is code that write code. In such case we can use serialization of code to XML, but I think it will be more useful to write such code directly in ruby ( or perl or whatever ). But the second case sounds wrong for me, as it allows hard to debug bugs, and we should avoid it as much as possible.
Also remember that you will need an automated migration of the data - and this will probably need to be shipped with new YaST. Jiri -- Regards, Jiri Srain Project Manager --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.com Lihovarska 1060/12 tel: +420 284 084 659 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.com -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 25.4.2013 12:40, Jiri Srain napsal(a):
Hi,
(sorry for top-posting)
Unfortunately, reading is not the only operation with the data - YaST also writes them quite extensively.
I don't really know what exactly the problem (internally) is, anyway, I have one suggstion:
Does reading/writing of the AutoYaST profiles, installation workflow definition and similar files work?
I tried the XML approach in the ntp-client, IMHO it looks better in this case, you can compare https://github.com/yast/yast-ntp-client/pull/6/files (XML solution) https://github.com/yast/yast-ntp-client/pull/5/files (include file) The advantage is that the data is XML file which can be read also by tools outside yast and it is a true data file (in contrast to include which is basically a piece of code). Any opinions? ----- P.S.: Here is the script which I used for creating the XML file: { // read "servers" content include "ntp-client/ntp_servers.ycp"; import "XML"; map doc = $[]; doc["cdataSections"] = []; doc["listEntries"] =$["ntp_servers":"ntp_server"]; doc["rootElement"] = "ntp_database"; doc["systemID"] = "/usr/share/YaST2/control/control.dtd"; doc["nameSpace"] = "http://www.suse.com/1.0/yast2ns"; doc["typeNamespace"] = "http://www.suse.com/1.0/configns"; XML::xmlCreateDoc(`ntp, doc); XML::YCPToXMLFile(`ntp, $[ "ntp_servers" : servers], "/tmp/ntp.xml"); } Then you can read the content by { import "XML"; y2internal("NTP: %1", XML::XMLToYCPFile("/tmp/ntp.xml")); } (BTW I had to manually fix the YCP data as there were some XML entities which made troubles when parsing back the saved XML file.) -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, 25 Apr 2013 16:06:24 +0200 Ladislav Slezak <lslezak@suse.cz> wrote:
Dne 25.4.2013 12:40, Jiri Srain napsal(a):
Hi,
(sorry for top-posting)
Unfortunately, reading is not the only operation with the data - YaST also writes them quite extensively.
I don't really know what exactly the problem (internally) is, anyway, I have one suggstion:
Does reading/writing of the AutoYaST profiles, installation workflow definition and similar files work?
I tried the XML approach in the ntp-client, IMHO it looks better in this case, you can compare
https://github.com/yast/yast-ntp-client/pull/6/files (XML solution) https://github.com/yast/yast-ntp-client/pull/5/files (include file)
The advantage is that the data is XML file which can be read also by tools outside yast and it is a true data file (in contrast to include which is basically a piece of code).
Any opinions?
From my point of view it is fine as long as such file is automatic generated. I really don't want to write such beast manually :) even reading it is pain. Question is what happen during installation as you read it now directory and before agent is used, so does it read from same location in both cases? Josef
-----
P.S.: Here is the script which I used for creating the XML file:
{ // read "servers" content include "ntp-client/ntp_servers.ycp"; import "XML";
map doc = $[]; doc["cdataSections"] = []; doc["listEntries"] =$["ntp_servers":"ntp_server"];
doc["rootElement"] = "ntp_database"; doc["systemID"] = "/usr/share/YaST2/control/control.dtd"; doc["nameSpace"] = "http://www.suse.com/1.0/yast2ns"; doc["typeNamespace"] = "http://www.suse.com/1.0/configns"; XML::xmlCreateDoc(`ntp, doc);
XML::YCPToXMLFile(`ntp, $[ "ntp_servers" : servers], "/tmp/ntp.xml"); }
Then you can read the content by
{ import "XML"; y2internal("NTP: %1", XML::XMLToYCPFile("/tmp/ntp.xml")); }
(BTW I had to manually fix the YCP data as there were some XML entities which made troubles when parsing back the saved XML file.)
--
Best Regards
Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 04/25/2013 04:37 PM, Josef Reidinger wrote:
On Thu, 25 Apr 2013 16:06:24 +0200 Ladislav Slezak <lslezak@suse.cz> wrote:
Dne 25.4.2013 12:40, Jiri Srain napsal(a):
Hi,
(sorry for top-posting)
Unfortunately, reading is not the only operation with the data - YaST also writes them quite extensively.
I don't really know what exactly the problem (internally) is, anyway, I have one suggstion:
Does reading/writing of the AutoYaST profiles, installation workflow definition and similar files work?
I tried the XML approach in the ntp-client, IMHO it looks better in this case, you can compare
https://github.com/yast/yast-ntp-client/pull/6/files (XML solution) https://github.com/yast/yast-ntp-client/pull/5/files (include file)
The advantage is that the data is XML file which can be read also by tools outside yast and it is a true data file (in contrast to include which is basically a piece of code).
Any opinions?
From my point of view it is fine as long as such file is automatic generated. I really don't want to write such beast manually :) even reading it is pain.
Question is what happen during installation as you read it now directory and before agent is used, so does it read from same location in both cases?
Well, when the code is migrated, the YCP data files will also be migrated; that's a matter of a simple YCP script. The more difficult part will be migration of data created on run-time... Jiri
Josef
-----
P.S.: Here is the script which I used for creating the XML file:
{ // read "servers" content include "ntp-client/ntp_servers.ycp"; import "XML";
map doc = $[]; doc["cdataSections"] = []; doc["listEntries"] =$["ntp_servers":"ntp_server"];
doc["rootElement"] = "ntp_database"; doc["systemID"] = "/usr/share/YaST2/control/control.dtd"; doc["nameSpace"] = "http://www.suse.com/1.0/yast2ns"; doc["typeNamespace"] = "http://www.suse.com/1.0/configns"; XML::xmlCreateDoc(`ntp, doc);
XML::YCPToXMLFile(`ntp, $[ "ntp_servers" : servers], "/tmp/ntp.xml"); }
Then you can read the content by
{ import "XML"; y2internal("NTP: %1", XML::XMLToYCPFile("/tmp/ntp.xml")); }
(BTW I had to manually fix the YCP data as there were some XML entities which made troubles when parsing back the saved XML file.)
--
Best Regards
Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/
-- Regards, Jiri Srain Project Manager --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.com Lihovarska 1060/12 tel: +420 284 084 659 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.com -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 25.4.2013 16:53, Jiri Srain napsal(a): [...]
The more difficult part will be migration of data created on run-time...
Yesterday I checked how YCP data files are used in Yast. There are basically these groups: - Static data - like NTP servers, sound card drivers, mouse types, phone codes... No migration needed, the new package will also contain new database which will be used instead of the old one. - Dynamically created data (by helper scrips) - some modules contain helper scripts (usually in perl or bash) which generate YCP output to stdout or file which is then read by Yast. No migration is needed if we also adapt the scripts. Either the data format can be changed to something else (YAML, plain text...) or the perl scripts could be modified to perl modules and be used directly via perl-bindings. (This would be also faster as no external process would be needed and the data would be directly converted to Yast types without the extra text representation in the middle.) - In most cases the data is saved to survive reboot/YaST restart (that's the case for installation, wagon, packager ...) Usually no migration is needed as these are just temporary internal data used only for one specific run and the data is not needed after package upgrade. - User preferences - like "don't show again" store, usually just simple values (like boolean or string) which could be even manually read/parsed from YCP file. And it should be also possible to not migrate the data at all, the user would be just asked once again, which IMHO is acceptable in some cases. - Complete configurations - like backup or add-on creator contain whole application configuration in YCP format. Also bootloader saves some part of the configuration to an YCP file. This is the most problematic part as there are important data which cannot be lost. Here we have to provide a conversion tool or somehow support reading the old format. Or we could release a maintenance update for the affected packages and it would write the config in the future format and the conversion would be also called in %post to ensure that the future version (without YCP support) will find the data already in the new format. What do you think about it? -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak@suse.com SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 26.4.2013 10:32, Ladislav Slezak napsal(a):
Dne 25.4.2013 16:53, Jiri Srain napsal(a): [...]
The more difficult part will be migration of data created on run-time...
BTW another option is to leave the YCP parser in .target.ycp agent and leave the code as it is now. The agent is independent part of YaST (it just reuses the YCP parser library) so we could leave YCP support in SCR but remove it from the interpreter. We could change the data where possible and leave the complex cases unchanged. This is still open and we need to actually define how much we want to "kill" YCP... -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak@suse.com SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Mon, Apr 29, 2013 at 11:56:06AM +0200, Ladislav Slezak wrote:
Dne 26.4.2013 10:32, Ladislav Slezak napsal(a):
Dne 25.4.2013 16:53, Jiri Srain napsal(a): [...]
The more difficult part will be migration of data created on run-time...
BTW another option is to leave the YCP parser in .target.ycp agent and leave the code as it is now. The agent is independent part of YaST (it just reuses the YCP parser library) so we could leave YCP support in SCR but remove it from the interpreter.
That leaves us with a big(?) amount of C++ code.
We could change the data where possible and leave the complex cases unchanged.
This is still open and we need to actually define how much we want to "kill" YCP...
We already have a parser for YCP data written in Perl: https://github.com/yast/yast-core/blob/master/agents-perl/lib/ycp.pm with tests: https://github.com/yast/yast-core/blob/master/agents-perl/lib/ycp.test so another option would be to call that: Ruby <-> YaST-without-YCP <-> Perl which is, uh, too multilingual I think. Or we could write a parser for YCP values (simpler than YCP code) in Ruby. -- Martin Vidner, Cloud & Systems Management Team http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
* Martin Vidner <mvidner@suse.cz> [Apr 30. 2013 11:00]:
Or we could write a parser for YCP values (simpler than YCP code) in Ruby.
Take it as an opportunity to clean up the respective parts of YaST. Once the mechanical translation is done, start by refactoring those code parts that read/write ycp files. Convert these to YaML or JSON. Decide on one representation and use it consistently everywhere. YCP values are sufficiently simple and should not(!) require an XML representation. Just my $0.02 ;-) Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 04/30/2013 11:47 AM, Klaus Kaempf wrote:
* Martin Vidner <mvidner@suse.cz> [Apr 30. 2013 11:00]:
Or we could write a parser for YCP values (simpler than YCP code) in Ruby.
Take it as an opportunity to clean up the respective parts of YaST.
Once the mechanical translation is done, start by refactoring those code parts that read/write ycp files.
Or we could start doing this in parallel already. Sometimes reading a file might not be needed at all or could use a simpler format than YCP which was selected just because it was the easiest way for us.
Convert these to YaML or JSON. Decide on one representation and use it consistently everywhere. YCP values are sufficiently simple and should not(!) require an XML representation.
Sounds good. Not having XML makes it human-readable and reduces the cost of reading/writing. Lukas -- Lukas Ocilka, Cloud & Systems Management Department SUSE LINUX s.r.o., Praha -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Hello, On Apr 30 15:51 Lukas Ocilka wrote (excerpt):
Not having XML makes it human-readable and reduces the cost of reading/writing.
I like simplistic doctrine very much - it makes things so easy! I neither state XML is the right solution to replace YCP data nor do I state usual XML data is well human-readable but I would appreciate it if decisions that must be future-proof are based on thorough analysis and not on individual personal preferences. For example if import/export of YaST data is of importance (or will become of importance in the future), XML+DTD may have advantages. In this case it could be good when there is only one single data format that is also used for import/export. One can include the DTD inline in the XML so that such an XML+DTD document is one single piece of data that can be sent anywhere (exported), changed there and validated there, and then re-imported. Perhaps YaST modules that run on host A may like to export configuration data to another host where the configuration data can be changed and validated and then the other host sends the changed configuration data back to the YaST module on host A where the imported data gets validated again (not only syntactically validated again but also validated against the actual environment on host A) and finally the changed configuration could be applied on host A. If XML with inline DTD would be used to store and exchange YaST data, arbitrary XML-compatible tools on arbitrary operating systems could be used to change any YaST data form any YaST version in a vaild way. Scary hint: Running a frontend on a Windows management host that communicates this way with various YaST backend modules running on various Linux hosts. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 04/29/2013 11:56 AM, Ladislav Slezak wrote:
Dne 26.4.2013 10:32, Ladislav Slezak napsal(a):
Dne 25.4.2013 16:53, Jiri Srain napsal(a): [...]
The more difficult part will be migration of data created on run-time...
BTW another option is to leave the YCP parser in .target.ycp agent and leave the code as it is now. The agent is independent part of YaST (it just reuses the YCP parser library) so we could leave YCP support in SCR but remove it from the interpreter.
We could change the data where possible and leave the complex cases unchanged.
This is still open and we need to actually define how much we want to "kill" YCP...
If we want to kill YCP, I'd prefer to kill it completely. YaST package should know where these YCP files are stored, converting the data during package upgrade (in %post) sounds like a good idea. Data IMO represent a single variable (hash, array, ...) so it's not a complete code actually. Writing a script for converting them should not be that hard and we could put it into the YaST Base package or into a special one if you prefer. The updated package would need to have the script (package) in "pre-requires". Lukas -- Lukas Ocilka, Cloud & Systems Management Department SUSE LINUX s.r.o., Praha -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (8)
-
Jiri Srain -
Johannes Meixner -
Josef Reidinger -
Klaus Kaempf -
Ladislav Slezak -
Lukas Ocilka -
Martin Vidner -
Thomas Fehr