Introducing live-xmaker
>> But you can't use Hook-Files in a Single LH_CONFFILE,
>> and thats what i need!
>>
>
> hook files can be arbitrary binaries. There are ways to encode them
> inside XLM, but why bother? Just add them as separate files.
>
> Likewise the contents of the local include directory.
>
>
In my daily life with the autobuild system (just a few changes to to the
wonderful webhelper) it is really a bless to keep your whole
configuration (including lists and hooks) in a single file. I used a
little hack to do this, see the included dirty.build if you are
interested in dirty details.
I really like how the config file is used at the moment in live-helper.
You probably need some non-live-helper informations for the build system
(where to put the image, update an db entry, generate a webpage or
whatever) and just throw them in there and use them as variables in the
build script. I really want to keep them the way they are and don't want
to replace them. But for build systems and archives I think that some
kind of "extented config file" really is needed, too.
I'm pretty sure when you hear live-helper and xml in the same sentence
your toe-nails are rolling back, thinking of the overhead (-:
As a big fan of the command line tool xml2 my first thought was using it
somehow in my private build system but than I could convince oliver to
write a little shell parser to spare the depends. It works reliable and
is small enough to include it.
In fact I think an extended (xml) config file could bring us a few nice
new features like "export the configuration including the used package
versions for later rebuilds", for support, in webservices allowing to
upload whole config with hooks and everything (including evil hacking
hooks ;-) )
A few points are waiting to be discussed like the problem with the
potential binary files (could not only be hooks, also be local packages
/ is uuencode evil?) but I really would love to see things like all this
in live-helper in a clean live-helperish way (-:
And of course because code says more than thousand words there is the
function "xml.sh", the helper "lh_xml" (for im- and export) and an
example config.xml attached to this mail.
a few details (but open for every kind of change/rewrite):
- export will only write non-default values
- only depends on hexdump (busybox version works too)
- fast (enough)
- nothing implimented for binary yet (but there is uuencode in
busybox, too)
Have fun trying out and see this as an attempt to wide out this
discussion to "lh <-> xml".
thanks for your time
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.xml
Type: text/xml
Size: 2905 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/debian-live-devel/attachments/20080822/d4ab3a3f/attachment.bin
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dirty.build
Url: http://lists.alioth.debian.org/pipermail/debian-live-devel/attachments/20080822/d4ab3a3f/attachment.txt
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lh_xml
Url: http://lists.alioth.debian.org/pipermail/debian-live-devel/attachments/20080822/d4ab3a3f/attachment-0001.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xml.sh
Type: application/x-sh
Size: 5168 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/debian-live-devel/attachments/20080822/d4ab3a3f/attachment.sh
Reply to: