Re: package manager thoughts

>> 1. XML and its use as a package manager(pm)?
> 
> I think XML is fantastic if it is machine generated and machine read but
> not ideal if you need to edit it manually.

We should use an extensible format that can have graceful degradation
depending on the reading software, i.e. XML Rdf.  Two examples of why come
to mind:

1. Classic example: Old programs stuck on machine, newly extended rdf ebuild
is downloaded with extra fields the old program didn't expect. In rdf, this
can be handled by having versioning and by stating which fields are
required and which are optional. So required fields will be very long-lived
(think stable genes) while optional fields, when present and not recognized
by an older program, can be ignored. 

2. Embedded twist on classic example: Assume you don't want to (and can't
generally) update your ZyPortage every freakin' *day* on an embedded
device. It would be excellent if embedded devices could still read newer
versions of ZyEbuilds, though! Further, embedded devices will probably want
to ignore much metadata in ebuilds, such as optional IUSE or CFLAGs or
whatever (even in the case of cross-compiling). Once again, having rdf and
hte graceful degradation it allows fits this need perfectly. I am still
rummaging for the best docs on the net to help explain how this is
implemented using rdf... But it's way cool stuff. 

Ok, finally, in response to the 'xml-vs.-plain text' debate. There are
plenty of viable solutions, I mean, we all use binary programs but hack on
source code! We don't complain that all of our software should be script
(i.e. the source is the only representation of the executable)! So we have
many decent solutions; here are two:
  1. Source is stored in rdf, people work with plain text which is 
     automatically converted ('compiled') back and forth
  2. Source is stored in rdf, and bash segments are xml included into 
     the file