Sorry for delay in answering this one, been up to here with RL, and I didn't have access to the debian and BSD bookmarks.
Sebastian Pipping wrote: > Steven J Long wrote: >> You might as well use Gentoo's version specification for your internal >> format, as it's the most comprehensive. The most you need to add is >> debian epochs. > > I'm not sure what you are referring to. > Please share more details or pointers. > There's two aspects: the category grouping, and the version specifier. Most distros have a flat namespace, which gets kinda hairy. One level of grouping above that makes a BIG difference. If you take a look here: http://sources.gentoo.org/viewcvs.py/portage/main/trunk/pym/portage/versions.py?view=markup you can see the version RE; note it can handle arbitrary levels of patch (pre etc.) This is what we use in update[1] to split an arbitrary CPV: CPV='^(.*-.*|virtual)/(.*)-([0-9]+)((\.[0-9]+)*)([a-z]?)((_(pre|p|beta alpha|rc)[0-9]*)*)(-r([0-9.]+))?$' (That's all one line.) If it doesn't match that, the CPV is not valid, and with the one RE match, we have all the constituent parts, though we don't often compare versions and handle that separately. We've removed cvs. prefix since it's supposed to be deprecated, and added the inter-rev bit for prefix portage. cvs. is still kept in our version comparison code as it's a pita to rewrite, and we're waiting for some sort of outcome to handling vcs builds; simply swapping two letters is clearly optimal. The "official" reasons given for deprecating cvs. were 1) no-one knew about it. 2) those who did apparently found it "hard to deal with" though one could be forgiven for thinking that's due to novelty; -rNN is supposedly "hard" too. 3) it's vendor-specific. We removed it for getCPV() as we call that function a *lot*; much more often than verCompare() and every little bit helps. Adding it back is a doddle. A prefix here is more efficient than yet another suffix. I've yet to see an upstream version that can't be handled adequately by the Gentoo versioning scheme. Granted you get the odd insane upstream; in those kind of cases, I'd rather go by date (which can ofc be handled easily) or svn id. A distro really should not have any need to push a version more than once a day, and the distro release bit at the end allows one to deal with the occasional mistake. Ultimately it's down to the maintainer, ofc, but I'd question the stability of a project that releases more than once per day; it does occasionally happen with bugfixes, usually with some sort of patch revision. WRT debian epochs, they're described here: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version You should also take a look at how *BSD handle eg LIB_DEPENDS (the LDEPEND variable I've occasionally suggested in the past): http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-depend.html I personally am not too fussed about the other *_DEPENDS mentioned therein; you might want to add them for completeness. > >> XML was never meant for data-storage for such record-sets: it was >> designed for data *interchange* [..] > > Interesting point. What would you use as an alternative that > works well with a version control system? > Ah didn't realise you wanted to keep this all in a vcs. Personally I'd use a format similar to the metadata section part of an ebuild, so simple shell assignments. I wouldn't worry about whether strings are single or double-quoted (or even if they're quoted at all, myself); just ban all backslashes, and have some sort of script that runs to verify pre-commit. There's no need to start going off into some nutty anxiety attack about "oh but sh allows X and BASH allows Y" imo; just verify that the data lexes fine: people make mistakes all the time. (It's only mildly tricky in C, so should be easy enough however you implement.) Having said that, XML is fine for microformats; Gentoo GuideXML is one of the nicest applications of XML I've seen (and was a factor in us going with Gentoo, believe it or not.) Nor is this a massive dataset. I just think most of your users will be more comfortable. Good luck with it, whatever format you go with. HTH, Steve. [1] http://forums.gentoo.org/viewtopic-t-546828.html -- the version on there is very much out of date (I'll get that modded soon, Naib ty for your lovely comments;) so if any Gentoo-user does want to try it: git clone git://weaver.gentooenterprise.com/update.git Please be aware this is under AGPL3+ for non-commercial use only, so if that bothers you, don't clone it. (Written with a work colleague, on work time. He wasn't happy with CC-NCSA as he's committed to FSF for some reason, a stance I have to say I am coming to agree with, but that's another [off;]topic.) -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)
