All the Perl that's Practical to Extract and Report

is freebsd on drugs?

rjbs on 2007-05-01T14:00:20

Gabor recenly posted some reports about what version of what CPAN dists were in what OS distributions.

I thought I'd have a look at one of the clusters of modules I maintain in the Email:: namespace. I headed to the E section and I saw something bizarre. Why does FreeBSD change so many version numbers? Email-FolderType is distributed as 0.8.12 instead of 0.812. Does that mean they only use X.Y.ZZZ? No, because Email-Folder 0.852 is distributed as 0.85.2. Does that mean they just require some form of three-part version? I don't think so, since Email-MIME 1.855 is distributed as 1.855.

Can someone tell me what the hell they're doing?

No clue

jk2addict on 2007-05-01T14:33:27

I have no idea, but I knew it happens. Something to do with the ports system and version numbers.

That's why dists like DBIx::Class and such started using 0.xxyyy as the verison number instead of 0.xx, because when things were stuffed into FBSD ports, it had crazy ideas of what things where newer than other things.

Re:No clue

jk2addict on 2007-05-01T14:34:39

In fact, from the DBIC source:

# Always remember to do all digits for the version even if they're 0
# i.e. first release of 0.XX *must* be 0.XX000. This avoids fBSD ports
# brain damage and presumably various other packaging systems too

$VERSION = '0.07006';

Re:No clue

lbr on 2007-05-02T07:06:11

That would be my fault. As the FreeBSD maintainer for DBIx::Class, I requested this, and I'm very happy it's now policy across both DBIC and Catalyst.

It's not because we can't handle the situation, like tagg describes, but it's simply more (error-prone) work for us. So personally I prefer not to.

No, FreeBSD is not on drugs

tagg on 2007-05-01T18:36:06

At least, not that I know of.

The simple reason is the algorithm that the FreeBSD Ports system uses to compare version numbers ( pkg_version(1) ). It can handle stuff like 0.01 < 0.02 and 0.99 < 1.01, but when an author, instead of incrementing the version number, just sticks another digit on the end, the version number comparison gets into trouble. Or more exactly, the trouble arises when that digit is removed. So 1.86 < 1.861, but 1.861 > 1.87! Not good.

In order to alleviate this problem, the ports maintainer can choose to rewrite the version number used in the ports dependency calculations, to make it compatible with the comparison algorithm. E.g. '3Beta7-pre2' becomes '3.b7.p2', and '1.861' becomes '1.86.1'. Since 1.86.1 < 1.87, we have avoided the problem.

Also note, that we do not change the version number in the module; only in the ports system. So code like "use Email::Address 1.871;" continues to work as usual.

So, as you can see, FreeBSD as no intention of usurping power over the version numbers; we are merely trying to evening out the impedance mismatches, and keeping everybody's systems going smoothly.

I bet that there are other packaging systems out there with similar difficulties, when it comes to universally correct version number comparison. For this reason, I would recommend module authors to stick with the simplest possible version numbering.

/Lars
FreeBSD committer and ports maintainer of several Email::* modules

Re:No, FreeBSD is not on drugs

rjbs on 2007-05-01T19:09:23

Thanks, that's nice and clear. I know FreeBSD isn't messing with the code for modules I maintain, unlike some OTHER distributions I could name. They probably have made me grumpier than I need to be.

My code is always X.YYY, except for Bundle modules, which are always of a different fixed digit format. This should be true of most PEP things, especially once it's standardized.

Feel free to keep doing what you're doing, of course. I'm just letting you know that I am not one of those lunatics who goes from 1.9 to 1.10 to 1.90.