[gentoo-dev] Re: Re: Inviting you to project "PackageMap"

[Steven J Long]

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 ;-)