On 29 June 2012 17:32, Duncan <1i5t5.dun...@cox.net> wrote: > > EUSCAN_VERSION=0.71 > > I don't know how difficult that would be for euscan to pickup on, but > since this would have no bearing on actual package behavior, only on > euscan, I'd guess it shouldn't require going thru the formal PMS process, > tho specifying it well enough to know whether it can be a function or > must be a straight variable assignment, etc, as well as whether quotes > are required or not, would be useful, and that's normally part of the PMS > process so at least getting input from them would be useful. > > Alternatively, define some formula that can be placed in the package's > metadata.xml. That's perhaps a better functionality match (we're talking > about metadata, after all), but getting a formula that can deal with all > the corner-cases is likely to be more difficult (and take longer) than > simply specifying a variable to be defined for each ebuild that euscan > can't immediately get correct.
The problem is with this approach, some devs will want to set EUSCAN_VERSION automagically using mangling $PV As it is, we *already* have something equivalent to EUSCAN_VERSION for things derived from perl-module.eclass, MODULE_VERSION= Its not 1:1 identical to the intent of EUSCAN_VERSION, MODULE_VERSION is only really required in the generation of SRC_URI , but because of this, there is a loose MODULE_VERSION <-> distfile mapping, and a much looser $PV <-> MODULE_VERSION association. Sure, its fine for MODULE_VERSION to be made by mangling $PV, but the problem is that the *reason* people mangle $PV to make MODULE_VERSION is so they don't have to update MODULE_VERSION manually when bumping the package. Adding a non-bash non-$PV-manglable field EUSCAN_VERSION field will possibly make manually incrementing this value a mandatory thing. Not to mention, if it turns out to be "wrong" on the EUSCAN index, some dev has to drop the change into the repository, do all the manifest updating and commit signing and pushing it to CVS nonsense, when really, its metadata only relevant to euscan, so its really in the wrong place to start with. Having it handled as an exception list on the euscan would be much tidier, and the path from noticing the problem to solving the problem becomes substantially shorter. -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
