Re: package validation (was Re: PHP_Beautifier-0.0.6.1)

On 6 Jun 2004 at 17:23, Tomas V.V.Cox wrote: > Greg Beaver wrote: > > Tomas V.V.Cox wrote: > > > >> The pear installer needs urgently, apart of a decent DTD validation, > >> one of these two: > >> > >> a) Remove any PEAR coding standar rule that is hardcoded today. > >> b) Provide something like a plug-in system which validates the > >> package.xml fields according to the rules of each "channel" developers. > > > > > > You really need to check out the code in PEAR-1.4.0dev5.tgz, in > > particular PEAR_PackageFile and PEAR_ChannelFile classes. A package > > name validation regex is already in channel.xml and is fully supported > > by the installer. > > IMHO this is not the place, see my opinions below. Same here. I wonder if additional checks might be useful that you can't do with a regex - e.g. testing for versionnumber and state- combination (linux-kernel-style where an odd number would demand beta- state) or so. Maybe a combination - so we allow for additional checks but make lightweight checks available by a regex. > > Far better than doing this in pre- and post- scripts is to leverage the > > existing power of polymorphism. Simply allow users to extend > > PEAR_PackageFile, and redefine the validation of package version. Most > > of this stuff should be server-side, and not in the pear packager, as > > things like this tend to change as the political decisions change. > > One idea could be. A new <php_dir>/PEAR/validations/ dir. Inside it > there would be one <channel> dir where validations stands. Each channel > team writes a package called for example: ChannelValidation_<channel > name>, which would contain any number of installable php files at > <php_dir>/PEAR/validations/<channel name>. Maybe it's too late for this discussion already *g* but would a <php_dir>/PEAR/chan_<channelname>/validations structure make sense, or is this out of scope? This way only the PEAR-packages themselves would be located directly under .../PEAR/ for historical reasons. Only drawback: There might still occur name-clashes between PEAR and non-PEAR-packages :-( Well, just some quick thoughts - the class-naming-problem however remains. And about package signing? Where do we put the keys ... Stefan