DragonFly kernel List (threaded) for 2003-10
Re: Xml in packaging system
Simon 'corecode' Schubert wrote:
okay, could we please first discuss requirements and taboos and then
the tools used before some people invest lots of time in something which
may not be accepted by the developers?
Just a few wishes.
1. I'd like to new port system to be hierarchy (tree). For example,
searching a tool in Devel directory (1178 items), or Perl - 1128 items,
net - 812 is no fun.
2. About port Makefile format. Currently it is really a bit strange: it
is a make file, with a lot of variables assignment, and a dosen of
"hooks": on-install, post-config, etc. It is non too natural to "make"
to deal with such kind of tasks.
I am thinking about some set of attributes that can be assigned to each
port. For example, how can I easy get list of all ports that depend on
X? A list of ports that gmake depend on?
I am thinking about having ports in a single xml file instead a file
system structure. All the queries can be done in XPATH queries, for example:
Hook implementations can be also quite easy:
xmlElement currentPortNode =
Ok, about xml performance. If use DOM model, it could be a problem, but
if rewrite it to utilize stream model (SAX interface), I do not think
it'll be an issue (but it would be impossible to use these fancy xpath
expressions). Or it would be possible to cache the most time consuming
data in some db files.
I'd like whole new port system to not be connected with some one tool
format, like makefile format is now. It is no easy way to parse needed
atributes now. Specific tool independent format (xml for example) will
give possibility to develop a set of a little tools each of that is
doing only one kind of task (security upgrade for example) but is doing
it wery well. And whole set of these tools will be called a ports
system. Isn't this a typical U*x design?
Also it would allow to compete several tools as soon as data format
(called "schema" in xml language) is stable.