At 16:50 Uhr -0500 02.02.2002, Kyle Moffett wrote: >I would like to propose a format for XML info documents for Fink. >Please note that this is very preliminary and subject to much >change, especially since the reason I'm putting this up here is so >that it can get changed, edited, customized, and finalized. Once >this is finalized, and even before, I will begin implementing the >feature-set. > >My idea of this includes a transition format, and a complete format. >The complete format will include things like variants and separate >packages from a single compile, stuff that is not implemented in the >core of Fink yet. That format will be created as we implement those >features. The 'transitional' feature-set would be a wrapper over >the existing Fink code that would simply parse the XML into the same >hash as the regular info files.
Actually, in my mind, there is no difference at all - even the "final" format would be parsed into the same hash format as we have now. The main difference is that multiple variants would generated multiple package entries. >Again, please provide any and all comments! Thank you! > > >Proposed transitional .xinfo format: > >Terminology: >Some fields will have values like 'foo, bar, or foobar' those >indicate multiple possible values. Some fields are surrounded by >braces [ foo='bar or foobar' ] those are optional, the default is >the first specified in the contents of the field, or none if the >field is empty. > ><package name="foo" version="0.0.1" revision="1" type="bundle, >nosource, or perl" essential="true or false"> > <maintainer name="John Doe" email="[EMAIL PROTECTED]"/> > > <require [type="depends, builddepends, provides, conflicts, >replaces or predepends"] package="bar"/> > <suggest [type="suggests, recommends, or enhances"] package="bar"/> I don't like this to much. <require type="provides"> feels awkward to me. So I personally would go for having different elements for each. Maybe like this: <depends package="foo"> <depends type="build" package="quux"/> <conflicts package="bar" version="<<1.0"/> > > <source url="http://open.source.site/directory/%n-%v.tar.gz"; >[ directory="%n-%v-2002" ] [ nodirectory="true" ] [ >rename="file1-%n-%v.tar.gz" ] /> > <custommirror> > <nam-US url="http://other.source.site/mirror/"/> > <asi-JP url="http://last.source.site.jp/mirror/"/> > </custommirror> Using the locations as element name is not good, since it prevents us from writing a proper DTD. I'd rather see something like this: <custommirror> <mirror continent="nam" country="US" url="http://other.source.site/mirror/"/> <mirror continent="asi" country="JP" url="http://last.source.site.jp/mirror/"/> </custommirror> > <update> > <configguess [ default="true or false" ] [ >dirs="mydir myotherdir"] /> > <libtool [ default="true or false" ] [ dirs="mydir >myotherdir"] /> > <pomakefile/> > <pod/> > </update> We don't need the "default" attribute you suggest, I think. I know you can currently say "UpdateConfigGuess: false", but that is completly superfloous to do, i.e. you could just as well leave out the line. > > <patch [ name="%f.patch" ] > ><![CDATA[ >patch -p1 script.here >]]> > </patch> // <-- Note here that patch is used >for both the patch and the patchscript, just leave out the contents >if you don't want the patchscript Nice idea, also I worry how feasible it is to include scripts directly - charachters like <, ", > and & occure quite frequently inside scripts. That is really an issue with XML, which we have to consider. > > <configure params="--insert --your=parems --here"> > <compilescript> ><![CDATA[ >make all >make foo >]]> > </compilescript> > <installscript> ><![CDATA[ >make install >make install-foo >]]> > </installscript> > > <doc files="README LICENSE COPYRIGHT INSTALL Stuff"/> That's not XMLish :) The files should be split up, like this: <docfiles> <file name="README"/> <file name="LICENSE"/> <file name="NEWS"/> </docfiles> [...] Cheers, Max -- ----------------------------------------------- Max Horn Software Developer email: <mailto:[EMAIL PROTECTED]> phone: (+49) 6151-494890 _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
