Re: [PATCH/RFC] deb-version.5: Add an own manpage for Dpkg's version format
Frank Lichtenheld writes ([PATCH/RFC] deb-version.5: Add an own manpage for Dpkg's version format): 1) If I would copy this text, who to credit for it? For now I just copied the copyright notice from Policy but I suspect that might not be the whole truth given how old it is. I haven't double-checked but I suspect it's pretty much the same text as I wrote all those years ago. 2) Should we really try to include more documentation of dpkg's behaviour in dpkg itself? (My answer is a clear yes to that) If yes, how do we avoid duplication with policy? After all we probably can't just delete such stuff from policy since there might be differences what dpkg supports and what policy allows. But not documenting dpkg features until they are allowed by Policy is not a good way either. Originally what is now the policy manual was two documents (both of which I wrote): * dpkg Programmers' Manual * Debian Policy Manual The former described the behaviour of dpkg, from a package maintainer's point of view, and documented the restrictions and requirements which are inherent in dpkg's behaviour. The latter described other decisions made by Debian which weren't direct consequences of the behaviour of dpkg. I wasn't there when it was decided to merge these, so I can't say for sure what the reasons were. Obviously before reversing this decision again it would be sensible to understand the reasons behind it, and to consider whether we agree with them and whether they still apply. Two obvious reasons I can think of are that it may have been felt confusing to maintainers to have to consult two documents, and that there may have been a desire to put the dpkg Programmers Manual into some kind of formal change process or at least to take it out of the hands of what were at the time the rather chaotic hands of the various dpkg maintainers. Personally I think merging this documents was a mistake and they should be separated again. However, others may disagree. Times have changed quite a bit. When these manuals were separate dpkg was the principal complex piece of code which handled packages. Now the higher-level tools like apt, archive management software, package tracking systems, etc. etc., all have reliance on the package format - so changing it isn't as simple as changing dpkg. On the other hand, the we need it in one place argument is less strong now, because nowadays we have a plethora of documents which a maintainer is expected to keep abreast of. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373003: [PATCH/RFC] deb-version.5: Add an own manpage for Dpkg's version format
Frank Lichtenheld writes ([PATCH/RFC] deb-version.5: Add an own manpage for Dpkg's version format): 1) If I would copy this text, who to credit for it? For now I just copied the copyright notice from Policy but I suspect that might not be the whole truth given how old it is. I haven't double-checked but I suspect it's pretty much the same text as I wrote all those years ago. 2) Should we really try to include more documentation of dpkg's behaviour in dpkg itself? (My answer is a clear yes to that) If yes, how do we avoid duplication with policy? After all we probably can't just delete such stuff from policy since there might be differences what dpkg supports and what policy allows. But not documenting dpkg features until they are allowed by Policy is not a good way either. Originally what is now the policy manual was two documents (both of which I wrote): * dpkg Programmers' Manual * Debian Policy Manual The former described the behaviour of dpkg, from a package maintainer's point of view, and documented the restrictions and requirements which are inherent in dpkg's behaviour. The latter described other decisions made by Debian which weren't direct consequences of the behaviour of dpkg. I wasn't there when it was decided to merge these, so I can't say for sure what the reasons were. Obviously before reversing this decision again it would be sensible to understand the reasons behind it, and to consider whether we agree with them and whether they still apply. Two obvious reasons I can think of are that it may have been felt confusing to maintainers to have to consult two documents, and that there may have been a desire to put the dpkg Programmers Manual into some kind of formal change process or at least to take it out of the hands of what were at the time the rather chaotic hands of the various dpkg maintainers. Personally I think merging this documents was a mistake and they should be separated again. However, others may disagree. Times have changed quite a bit. When these manuals were separate dpkg was the principal complex piece of code which handled packages. Now the higher-level tools like apt, archive management software, package tracking systems, etc. etc., all have reliance on the package format - so changing it isn't as simple as changing dpkg. On the other hand, the we need it in one place argument is less strong now, because nowadays we have a plethora of documents which a maintainer is expected to keep abreast of. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[PATCH/RFC] deb-version.5: Add an own manpage for Dpkg's version format
I was looking for a way to really close #373003 (dpkg-dev: deb-control.5 old rule for Version hyphenation). In the end it lead me to the conclusion that Dpkg should contain a full description of its Version format, which in turn lead to completly copying the section from Policy since this is probably the best description available. This of course again leads to a few followup questions: 1) If I would copy this text, who to credit for it? For now I just copied the copyright notice from Policy but I suspect that might not be the whole truth given how old it is. 2) Should we really try to include more documentation of dpkg's behaviour in dpkg itself? (My answer is a clear yes to that) If yes, how do we avoid duplication with policy? After all we probably can't just delete such stuff from policy since there might be differences what dpkg supports and what policy allows. But not documenting dpkg features until they are allowed by Policy is not a good way either. 3) What do people think of this specific case of copying? Worth it? Should I try to condense the information more? What should we do with the text is policy? Comments welcome. Gruesse, Frank --- debian/changelog |2 + man/ChangeLog |9 man/deb-control.5 |7 ++- man/deb-version.5 | 124 + 4 files changed, 139 insertions(+), 3 deletions(-) create mode 100644 man/deb-version.5 diff --git a/debian/changelog b/debian/changelog index 6c33f1c..9facda3 100644 --- a/debian/changelog +++ b/debian/changelog @@ -35,6 +35,8 @@ dpkg (1.14.7) UNRELEASED; urgency=low Closes: #379418 * Let dpkg-buildpackage error out early if the version number from the changelog is not a valid Debian version. Closes: #216075 + * Add an own manpage for Dpkg's version format. Mostly stolen +from policy. Closes: #373003 [ Updated dpkg translations ] * Basque (Piarres Beobide). Closes: #440859 diff --git a/man/ChangeLog b/man/ChangeLog index fcc2e1a..42bdc37 100644 --- a/man/ChangeLog +++ b/man/ChangeLog @@ -1,3 +1,12 @@ +2007-10-06 Frank Lichtenheld [EMAIL PROTECTED] + + * deb-control.5: Move description of + version format to... + * deb-version.5: Take the section from + policy describing version format and + sorting since this is probably as good + as it gets for describing these. + 2007-09-30 Frank Lichtenheld [EMAIL PROTECTED] * deb-control.5: Remove obsolete sentence regarding diff --git a/man/deb-control.5 b/man/deb-control.5 index efc40c7..7043ef6 100644 --- a/man/deb-control.5 +++ b/man/deb-control.5 @@ -31,9 +31,9 @@ generate file names by most installation tools. .BR Version: version string Typically, this is the original package's version number in whatever form the program's author uses. It may also include a Debian revision number -(for non-native packages). If both version and revision are supplied, -they are separated by a hyphen, `-'. For this reason, the original version -may not have a hyphen in its version number. +(for non-native packages). The exact format and sorting algorithm +are described in +.BR deb-version (5). .TP .BR Maintainer: fullname email Should be in the format `Joe Bloggs [EMAIL PROTECTED]', and is typically @@ -219,6 +219,7 @@ Description: GNU grep, egrep and fgrep. . .SH SEE ALSO .BR deb (5), +.BR deb-version (5), .BR debtags (1), .BR dpkg (1), .BR dpkg-deb (1). diff --git a/man/deb-version.5 b/man/deb-version.5 new file mode 100644 index 000..ea273ec --- /dev/null +++ b/man/deb-version.5 @@ -0,0 +1,124 @@ +.\ Author: ?? +.\ Includes text from the Debian Policy by ?? +.TH deb\-version 5 2007-10-06 Debian Project Debian +.SH NAME +deb\-version \- Debian package version number format +. +.SH SYNOPSIS +.RI [ epoch :] upstream_version [\- debian_revision ] +.SH DESCRIPTION +Version numbers as used for Debian binary and source packages +consist of three components. These are: +.TP +.I epoch +This is a single (generally small) unsigned integer. It +may be omitted, in which case zero is assumed. If it is +omitted then the \fIupstream_version\fP may not +contain any colons. +.IP +It is provided to allow mistakes in the version numbers +of older versions of a package, and also a package's +previous version numbering schemes, to be left behind. +.TP +.I upstream_version +This is the main part of the version number. It is +usually the version number of the original (upstream) +package from which the \fI.deb\fP file has been made, +if this is applicable. Usually this will be in the same +format as that specified by the upstream author(s); +however, it may need to be reformatted to fit into the +package management system's format and comparison +scheme. +.IP +The comparison behavior of the package management system +with respect to the \fIupstream_version\fP is +described below. The \fIupstream_version\fP +portion of the version number is mandatory. +.IP +The
Bug#373003: [PATCH/RFC] deb-version.5: Add an own manpage for Dpkg's version format
I was looking for a way to really close #373003 (dpkg-dev: deb-control.5 old rule for Version hyphenation). In the end it lead me to the conclusion that Dpkg should contain a full description of its Version format, which in turn lead to completly copying the section from Policy since this is probably the best description available. This of course again leads to a few followup questions: 1) If I would copy this text, who to credit for it? For now I just copied the copyright notice from Policy but I suspect that might not be the whole truth given how old it is. 2) Should we really try to include more documentation of dpkg's behaviour in dpkg itself? (My answer is a clear yes to that) If yes, how do we avoid duplication with policy? After all we probably can't just delete such stuff from policy since there might be differences what dpkg supports and what policy allows. But not documenting dpkg features until they are allowed by Policy is not a good way either. 3) What do people think of this specific case of copying? Worth it? Should I try to condense the information more? What should we do with the text is policy? Comments welcome. Gruesse, Frank --- debian/changelog |2 + man/ChangeLog |9 man/deb-control.5 |7 ++- man/deb-version.5 | 124 + 4 files changed, 139 insertions(+), 3 deletions(-) create mode 100644 man/deb-version.5 diff --git a/debian/changelog b/debian/changelog index 6c33f1c..9facda3 100644 --- a/debian/changelog +++ b/debian/changelog @@ -35,6 +35,8 @@ dpkg (1.14.7) UNRELEASED; urgency=low Closes: #379418 * Let dpkg-buildpackage error out early if the version number from the changelog is not a valid Debian version. Closes: #216075 + * Add an own manpage for Dpkg's version format. Mostly stolen +from policy. Closes: #373003 [ Updated dpkg translations ] * Basque (Piarres Beobide). Closes: #440859 diff --git a/man/ChangeLog b/man/ChangeLog index fcc2e1a..42bdc37 100644 --- a/man/ChangeLog +++ b/man/ChangeLog @@ -1,3 +1,12 @@ +2007-10-06 Frank Lichtenheld [EMAIL PROTECTED] + + * deb-control.5: Move description of + version format to... + * deb-version.5: Take the section from + policy describing version format and + sorting since this is probably as good + as it gets for describing these. + 2007-09-30 Frank Lichtenheld [EMAIL PROTECTED] * deb-control.5: Remove obsolete sentence regarding diff --git a/man/deb-control.5 b/man/deb-control.5 index efc40c7..7043ef6 100644 --- a/man/deb-control.5 +++ b/man/deb-control.5 @@ -31,9 +31,9 @@ generate file names by most installation tools. .BR Version: version string Typically, this is the original package's version number in whatever form the program's author uses. It may also include a Debian revision number -(for non-native packages). If both version and revision are supplied, -they are separated by a hyphen, `-'. For this reason, the original version -may not have a hyphen in its version number. +(for non-native packages). The exact format and sorting algorithm +are described in +.BR deb-version (5). .TP .BR Maintainer: fullname email Should be in the format `Joe Bloggs [EMAIL PROTECTED]', and is typically @@ -219,6 +219,7 @@ Description: GNU grep, egrep and fgrep. . .SH SEE ALSO .BR deb (5), +.BR deb-version (5), .BR debtags (1), .BR dpkg (1), .BR dpkg-deb (1). diff --git a/man/deb-version.5 b/man/deb-version.5 new file mode 100644 index 000..ea273ec --- /dev/null +++ b/man/deb-version.5 @@ -0,0 +1,124 @@ +.\ Author: ?? +.\ Includes text from the Debian Policy by ?? +.TH deb\-version 5 2007-10-06 Debian Project Debian +.SH NAME +deb\-version \- Debian package version number format +. +.SH SYNOPSIS +.RI [ epoch :] upstream_version [\- debian_revision ] +.SH DESCRIPTION +Version numbers as used for Debian binary and source packages +consist of three components. These are: +.TP +.I epoch +This is a single (generally small) unsigned integer. It +may be omitted, in which case zero is assumed. If it is +omitted then the \fIupstream_version\fP may not +contain any colons. +.IP +It is provided to allow mistakes in the version numbers +of older versions of a package, and also a package's +previous version numbering schemes, to be left behind. +.TP +.I upstream_version +This is the main part of the version number. It is +usually the version number of the original (upstream) +package from which the \fI.deb\fP file has been made, +if this is applicable. Usually this will be in the same +format as that specified by the upstream author(s); +however, it may need to be reformatted to fit into the +package management system's format and comparison +scheme. +.IP +The comparison behavior of the package management system +with respect to the \fIupstream_version\fP is +described below. The \fIupstream_version\fP +portion of the version number is mandatory. +.IP +The