Re: [PATCH] Specify policy for use of revision IDs in version numbers
On May 1, 2011 seanius wrote: On Sat, Apr 30, 2011 at 03:51:15PM -0700, Russ Allbery wrote: I don't think it's Policy's place to tell people that they can't use hashes because they *might* result in long version numbers. They usually don't. +1. otherwise, this seems more like a guideline that ought to be in the developer's reference rather than enshrined as a MUST in policy. I agree with the position articulated by Russ and Sean here. In any cases hashes are only one way that version numbers can get long. Even if you think putting hashes in version numbers is not useful, I'm pretty sure we don't want to enumerate every possible thing that is not permitted in version numbers. I'd think the obvious place to start would be for policy to specify limits on version length. Maybe I missed something, but I didn't see anything like that. David. P.S. I'm not subscribed to the list. pgpEKYcIRbhI8.pgp Description: PGP signature
Re: [PATCH] Specify policy for use of revision IDs in version numbers
On Thu, May 05, 2011 at 12:46:15PM +0200, Guillem Jover wrote: On Sun, 2011-05-01 at 17:27:39 +0200, Bill Allombert wrote: On Sat, Apr 30, 2011 at 09:00:14PM -0700, Russ Allbery wrote: Also there are no technical requirement for packages filenames in ISO images to be canonical packages names. Packages filename can be mangled to fit the medium, there is a program 'dpkg-name' to recover the canonical packages name. Exactly, we could also add a new option to dpkg-name to select which naming layout to use, for example: --layout=(default|msdos|iso9960|joliet|sha1sum|...) or something along these lines. Currently dpkg-split already has a --msdos option to generate a 8.3 filename for the split files, which could be deprecated in favour of dpkg-name instead. This requires the same mangling to be applied to the filenames in the Packages files, but this not an issue since the Packages file is in the same medium. Well, this has already been solved long time ago, although the restrictions were different then, the dselect methods have supported the MSDOS-Filename field as a fallback to the Filename one. So the Packages file is usable not only for CDs/DVDs. The problem is that it seems that most (at least apt, cupt and smart) of the other front-ends do not support such field, so support would need to be added first. At that point the field could be named more appropriately I guess. I'm adding this to the things to discuss with dpkg front-end developer. Please, let's not go this way. We're not talking about needing incredibly limited filename lengths like 8.3 for FAT here. -- Steve McIntyre, Cambridge, UK.st...@einval.com We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs. -- Mike Andrews -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110511160010.gz32...@einval.com
Re: [PATCH] Specify policy for use of revision IDs in version numbers
Hi! On Wed, 2011-05-11 at 17:00:17 +0100, Steve McIntyre wrote: On Thu, May 05, 2011 at 12:46:15PM +0200, Guillem Jover wrote: Well, this has already been solved long time ago, although the restrictions were different then, the dselect methods have supported the MSDOS-Filename field as a fallback to the Filename one. So the Packages file is usable not only for CDs/DVDs. The problem is that it seems that most (at least apt, cupt and smart) of the other front-ends do not support such field, so support would need to be added first. At that point the field could be named more appropriately I guess. I'm adding this to the things to discuss with dpkg front-end developer. Please, let's not go this way. We're not talking about needing incredibly limited filename lengths like 8.3 for FAT here. Oh! I guess it was not clear from what I wrote above. I meant that as non of the other front-ends support MSDOS-Filename, then once and if support for shorter names gets implemented for the rest then we can use an updated field name and length restriction in line with current reality. Say, for example Short-Filename, and iso9960 file name length. regards, guillem -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110512002506.ga9...@gaara.hadrons.org
Re: [PATCH] Specify policy for use of revision IDs in version numbers
Hi! On Sun, 2011-05-01 at 17:27:39 +0200, Bill Allombert wrote: On Sat, Apr 30, 2011 at 09:00:14PM -0700, Russ Allbery wrote: 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. dpkg -l only truncates the output on terminals, and then only if the width is not enough to display the whole thing. aptitude seems to be truncating always the version to 10 characters, regardless of terminal width. 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. Right. Also there are no technical requirement for packages filenames in ISO images to be canonical packages names. Packages filename can be mangled to fit the medium, there is a program 'dpkg-name' to recover the canonical packages name. Exactly, we could also add a new option to dpkg-name to select which naming layout to use, for example: --layout=(default|msdos|iso9960|joliet|sha1sum|...) or something along these lines. Currently dpkg-split already has a --msdos option to generate a 8.3 filename for the split files, which could be deprecated in favour of dpkg-name instead. This requires the same mangling to be applied to the filenames in the Packages files, but this not an issue since the Packages file is in the same medium. Well, this has already been solved long time ago, although the restrictions were different then, the dselect methods have supported the MSDOS-Filename field as a fallback to the Filename one. So the Packages file is usable not only for CDs/DVDs. The problem is that it seems that most (at least apt, cupt and smart) of the other front-ends do not support such field, so support would need to be added first. At that point the field could be named more appropriately I guess. I'm adding this to the things to discuss with dpkg front-end developer. regards, guillem -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110505104615.gb20...@gaara.hadrons.org
Re: [PATCH] Specify policy for use of revision IDs in version numbers
Le Mon, May 02, 2011 at 06:09:11PM -0300, Henrique de Moraes Holschuh a écrit : The commit info varies per upload, it doesn't make sense to modify debian/copyright at every upload, better have that in the ONE place you must modify anyway. I recently started do this regularly for packages I maintain, with a commit message indicating that I searched the diff with the previous version packaged by Debian for new copyright notices or license statements. Cheers, -- Charles Plessy Illkirch-Graffenstaden, Alsace, France -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110503072448.ga11...@merveille.plessy.net
Re: [PATCH] Specify policy for use of revision IDs in version numbers
On Sun, 01 May 2011, Bill Allombert wrote: On Sat, Apr 30, 2011 at 09:00:14PM -0700, Russ Allbery wrote: 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. Also there are no technical requirement for packages filenames in ISO images to be canonical packages names. Packages filename can be mangled to fit the medium, there is a program 'dpkg-name' to recover the canonical packages name. This requires the same mangling to be applied to the filenames in the Packages files, but this not an issue since the Packages file is in the same medium. That could work, but I can certainly imagine non-uniqueness causing problems. .debs from inside a CD/DVD have this nasty tendency to show up in the most strange places. They don't stay put in that DVD/CD and get destroyed at the next point release. And it would cause problems for some tools, too. Assuming such package name reduction can be made to work safely, the question is: what would be the better solution in the long term? -- 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-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502212014.gb18...@khazad-dum.debian.net
Re: [PATCH] Specify policy for use of revision IDs in version numbers
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-policy-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
Re: [PATCH] Specify policy for use of revision IDs in version numbers
Le Sun, May 01, 2011 at 09:42:17AM -0300, Henrique de Moraes Holschuh a écrit : 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. Hello everybody, I wonder if the full repository and commit identification would not better belong to the Debian copyright file. See §12.5, paragraph 2: “the copyright file must say where the upstream sources (if any) were obtained.” Cheers, -- Charles Plessy Illkirch-Graffenstaden, Alsace, France -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501150045.gb10...@merveille.plessy.net
Re: [PATCH] Specify policy for use of revision IDs in version numbers
On Sat, Apr 30, 2011 at 09:00:14PM -0700, Russ Allbery wrote: 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. Also there are no technical requirement for packages filenames in ISO images to be canonical packages names. Packages filename can be mangled to fit the medium, there is a program 'dpkg-name' to recover the canonical packages name. This requires the same mangling to be applied to the filenames in the Packages files, but this not an issue since the Packages file is in the same medium. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501152739.GI19957@yellowpig
Re: [PATCH] Specify policy for use of revision IDs in version numbers
Ben Hutchings b...@decadent.org.uk (30/04/2011): --- This is based on recent discussions on debian-devel. There was not complete agreement, but I believe this reflects consensus. Ben. policy.sgml | 23 +++ 1 files changed, 23 insertions(+), 0 deletions(-) diff --git a/policy.sgml b/policy.sgml index 91173a5..2cc2d1e 100644 --- a/policy.sgml +++ b/policy.sgml @@ -934,6 +934,29 @@ /p /sect1 + sect1 + headingVersion numbers based on revision IDs/heading + + p + If the upstream version is a snapshot from a version + control system, the upstream version number may + incorporate a linear revision ID from the version control + system. For example, a Subversion or Mercurial revision + ID can be used if all snapshots are taken from the same + repository and branch. A commit count from prgngit + describe/prgn output can be used if all snapshots are + taken from the same branch which is not rebased or + otherwise rolled back. + /p + p + The upstream version number must not include a non-linear + revision ID or hash, since it cannot help in ordering + versions and it tends to result in very long version + numbers and filenames. This information may be recorded + in the changelog instead. + /p + /sect1 + /sect sect id=maintainer Seconded; thanks, Ben. Mraw, KiBi. signature.asc Description: Digital signature
Re: [PATCH] Specify policy for use of revision IDs in version numbers
Ben Hutchings b...@decadent.org.uk writes: + p + The upstream version number must not include a non-linear + revision ID or hash, since it cannot help in ordering + versions and it tends to result in very long version + numbers and filenames. This information may be recorded + in the changelog instead. + /p I don't think it's Policy's place to tell people that they can't use hashes because they *might* result in long version numbers. They usually don't. 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. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wribic9o@windlord.stanford.edu
Re: [PATCH] Specify policy for use of revision IDs in version numbers
On Sat, Apr 30, 2011 at 03:51:15PM -0700, Russ Allbery wrote: Ben Hutchings b...@decadent.org.uk writes: + p + The upstream version number must not include a non-linear + revision ID or hash, since it cannot help in ordering + versions and it tends to result in very long version + numbers and filenames. This information may be recorded + in the changelog instead. + /p I don't think it's Policy's place to tell people that they can't use hashes because they *might* result in long version numbers. They usually don't. 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. +1. otherwise, this seems more like a guideline that ought to be in the developer's reference rather than enshrined as a MUST in policy. sean -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110430225858.ga18...@cobija.connexer.com
Re: [PATCH] Specify policy for use of revision IDs in version numbers
Hi, On Sat, Apr 30, 2011 at 03:51:15PM -0700, Russ Allbery wrote: Ben Hutchings b...@decadent.org.uk writes: + p + The upstream version number must not include a non-linear + revision ID or hash, since it cannot help in ordering + versions and it tends to result in very long version + numbers and filenames. This information may be recorded + in the changelog instead. + /p It is a bit detailed and lacks limitation for length but I think it is a good start. The above goes to as 3.2.2 as I understand. We already have 3.2.1 Version numbers based on dates and fits nicely into the context. Let's add this. I don't think it's Policy's place to tell people that they can't use hashes because they *might* result in long version numbers. They usually don't. 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. I understand some may feel general recommendation to be in Developer's reference in general as: 5.11.2. NMUs and debian/changelog http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu-changelog This only talk about NMU versioning. 6.3. Best practices for debian/changelog http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-debian-changelog These are a bit more guidance than limiting version number for what we can use. 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. Osamu -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501003325.ga3...@debian.org
Re: [PATCH] Specify policy for use of revision IDs in version numbers
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: * 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 (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tydfrrxt@windlord.stanford.edu
