Tzafrir Cohen wrote:
> tar czf debian_live_config_in_a_single_file.tar.gz config/ utils/
> utils/ is a subdirectory with my little scripts.
> What extra meta data is there that can not be expressed using some other
> variables in config/common or config/your_own_file ?
> I can also store them in things such as version control. I don't really
> want to think at how your XML file looks in a version control, as all
> major ones are plain-text based. It's too easy to merge just the
> beginning of a tag and not its end.
It sounds like you have found a working chain for you. So, I found mine (-:
In fact I'm using repos and don't include "local-packages". And I've
never seen a binary hook or thought about writing one. So for my daily
work it works like a charm. I can make small edits without packing and
unpacking or something like this and in general I use it for storing the
image configurations, build and test them in intervals.
If I want to do bigger changes, I call lh_xml --import, work and test in
the config/ and pack it at the end with my lh_xml --export.
There is a question down there about not calling Import and Export. You
should check your mail programm. There was a file attached called
"lh_xml" without an extension (so modern mail software don't paste them
below the mail). The xml.sh is just a function (->
Maybe it will make a few things clearer.
> This is the "extra layer of translation" I entioned before.
At least we keep the original live-helper structure in the file. Maybe
even the lh_xml isn't the best example (that's all it is supposed to be).
A good structure would be to decide after a "lh_config -c" there should
be decided what function to use and lh_xml should be called lh_export or
something, with Attributes to maybe include binary, try to figure out
package versions, ...
> I use it in deb packages where the diff must be textual. uuencode is the
> easiest way to add e.g. extra images. Now try to browse funny.gif.uu
> with your favorite image browser.
> It is a bad design to start with.
browse images? on my build system?
>> - export will only write non-default values
> BTW: I believe that lh_config should write just non-default values as
> well. If the defualts change, old configurations still carry the old
100% correct. maybe an attribute worth, but default should be a complete
dump of the config.
> I'll note that your attached script does not actually implement
> XML_Import and XML_Export
see my first statement
sorry I cutted so many parts out, but the mail is way to long to read
anyway (my fault). but I have read and recognised it all.
thanks for the comments :-)
PS: at first I mailed this direct to you tzafrir, sorry was a misstake.
Will answer to the list in further mailings (-: