Re: package.xml 2.0 dilemma

this sounds like a good start, I'm tempted to look at the code for this and make it more solid. like: - show warnings where it's making risky assumptions - add getMeta($key) to PEAR_Package_v1, to retreive extra details from the XML file (eg. like <channel> </channel> tags..... etc.) >From my look at the code, there is no restriction on adding tags to V1 files and it's trivial to add support for extra tags which could be stored as meta data(which would be ignored by older versions) and available to autogenerate more consise V2 files. Regards Alan On Wed, 2005-06-08 at 22:13 -0400, Greg Beaver wrote: > Alan Knowles wrote: > > > > > > > > >>For a simple package like the svn extension, I would recommend simply > >>maintaining the package.xml 1.0 and use "pear convert" to spit out an > >>equivalent package.xml 2.0. > >> > >> > > > >is there any reason why "pear package" can not run "pear convert" > >internally to generate a package2.xml which is only stored in the > >tarball? > > > None other than the severe risk of magic involved. Several elements not > present in package.xml 1.0 are added (guessed) by the conversion > process, particularly a php dependency (it guesses 4.0.0 or higher if > nothing is specified). > > I would say if you're always happy with the auto-convert, perhaps an > option to pear package would fix this? > > $ pear package --convert > > Greg >