Re: [PATCH] Specify policy for use of revision IDs in version numbers
Osamu Aoki <osamu@debian.org> writes:
> This is another topic. I do not think everyone agreed yet to a
> particular set of numbers. The more I looked into this issue, I think
> followings are the possible numbers:
> * package file name for normal uploads: 90 characters (must)
> - rationale: UCS-2 requirement etc.
> - current longest is 76 chars.
> - this number is ready for policy.
> * package name length <=40 (must: 99.8% qualifies)
> * package name length <=30 (should: 98.3% qualifies)
> - aptitude field length default
> normal version length withour special extension such as +nmu? +b? ...
> should be:
> * version length <=30 (must: 99.9% qualifies)
> <=20 (must: 99.0% qualifies) possible alternative.
> * version length <=15 (should: 95.3% qualifies)
> - aptitude field length default can be 15 as BTS #624542 for 80 char/line
> - 10 is too short since only 83.8% qualifies.
So the reason for imposing a length restriction on version numbers in
particular is due to the UI display of aptitude? I'm a bit dubious that
this is a good justification for a Policy rule. dpkg -l has truncated
version numbers for forever at 14 characters, and I don't recall this
being a major issue in the past. The thing that started off this thread,
I thought, was the constraint on file name length in ISO images, which is
the total length and doesn't impose a constraint specifically on the
version.
>> If we have a version number length restriction, or an overall filename
>> length restriction, we should just say that, and point out that using
>> hashes may make it hard to meet the restriction.
> If we do this, we also need to move 3.2.1 to developers-reference.
I don't agree. That section is there because of a technical failure
caused by poorly-chosen date-based version numbers. As discussed in the
long thread in debian-devel, the use of hashes is as a supplement to a
sequential version, to identify a precise commit reliably.
I would support adding a statement to Policy akin to the advice in 3.2.1
pointing out that hashes don't sort reasonably and hence can't be relied
upon to order the version number, and that the part of the version prior
to the hash has to establish a unique sort. (That's a bad way of phrasing
it, of course.) But just banning them doesn't feel justified to me.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: