On 08/27/2009 10:04 AM, Chuck Lever wrote: > On Aug 26, 2009, at 7:56 PM, Lans Carstensen wrote: >> Chuck Lever wrote: >>> On Aug 26, 2009, at 2:03 PM, Steve Dickson wrote: >>>> On 08/26/2009 11:35 AM, Chuck Lever wrote: >>>>> On Aug 26, 2009, at 11:13 AM, Steve Dickson wrote: >>>>>> On 08/26/2009 10:28 AM, Chuck Lever wrote: >>>>>>> >>>>>>> On Aug 26, 2009, at 12:59 AM, Lans Carstensen wrote: >>>>>>> >>>>>>>> commit d3bb692a8c26c2d4e0dc70d7d0359daf79090e1e >>>>>>>> Author: Lans Carstensen <Lans.Carstensen@xxxxxxxxxxxxxx> >>>>>>>> Date: Tue Aug 25 21:52:03 2009 -0700 >>>>>>>> >>>>>>>> Bump nfs-iostat.py version up to 0.3 to reflect new features. >>>>>>> >>>>>>> Now that nfs-iostat.py has been integrated into nfs-utils, I'm >>>>>>> not sure >>>>>>> we want to maintain an individual version number for it. Maybe it >>>>>>> should use the nfs-utils package's versioning instead... Steve, your >>>>>>> thoughts? >>>>>> Hmm... I don't think we tie any of other commands versions to >>>>>> the package version.... >>>>> >>>>> Actually many of the C commands do grab a macro defined during >>>>> autoconfiguration: PACKAGE_VERSION. >>>>> >>>> Interesting.. I do see PACKAGE_VERSION being defined in >>>> support/include/config.h >>>> I guess I didn't know that was there and it does not seem to be used >>>> by anybody... which is probably a problem but I don't think its a >>>> problem >>>> with this script... >>> Right, I'm suggesting now would be a good time to switch these >>> scripts over to the package-wide versioning scheme. >>> But take a look at mount, statd, showmount, and nfsstat, at least: >>> these, for example, use the VERSION macro in their -V and usage >>> messages. >> >> I agree with that concept but I'll kindly defer on the implementation >> as I'm not exactly sure what would be required. > > That's quite alright. Probably Steve should cook something up for this > one. Yeah... don't get get hung up on this one... I'll deal with it... steved. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
