Re: [PATCH] Specify policy for use of revision IDs in version numbers
On Sat, 30 Apr 2011, Russ Allbery wrote:
> 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:
No, but I'd like to have a MUST rule that says that you MUST specify the
full repository and commit identification data in the 'new upstream'
changelog entry when you package out of a VCS repository instead of a
public release tarball. Maybe with examples for git, svn, mercurial and
bzr on the grounds that they're the most used ones right now and it
should get the idea across nicely).
> > * 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
No, it is because package file name + version string + other stuff
(arch, .deb/.udeb/?, "_" field separators...) must not exceed 90
characters... who cares if the tool won't show >10 chars by default?
Request a new default for the tool, or fix it in your local config if it
bothers you (I had to configure aptitute to show 20 chars plus suite to
suit my local needs, for example).
AND since you need to vary the arch and version strings outside of
maintainer control (new ports, NMUs, binNMUs, security updates,
backports...) you must have some space reserved for that.
When we arrive at the final numbers, we really should ALSO mandate the
maximum length of arch names and also change the "p-u" and security
updates versioning to be bounded and shorter (i.e. use a short pattern
with the debian release number that is other-distros-friendly, not its
codename), etc.
Otherwise it is a moot effort.
> > 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.
When we mandate anything re. version numbers, it better be in policy as
SHOULD or MUST, yes.
> 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.
I advise that the supporters of VCS-commit-hashes in version strings to
help write a footnote in policy (and maybe a full text in d-reference)
about how to properly deal with variable-length commit ids used as
version, when they exceed the maximum size. It requires some thought to
do it right in a way that it won't cause issues for any future commits.
Since we had to do it for the much easier to understand "date"-style
safe patterns for version strings because people were screwing it up in
practice and epochs were needed to repair the damage, we better do it
for VCS commit ids as well. There is no reason to believe history won't
repeat itself.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: