On Sat, 30 Apr 2011, Russ Allbery wrote: > Osamu Aoki <os...@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 -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501124217.ga19...@khazad-dum.debian.net