Ian Jackson <[EMAIL PROTECTED]> said: > There are a couple of things I want to set people straight on, in this > area: > > * dpkg and other packages written especially for Debian don't have a > revision number because a revision number would be meaningless and > confusing. The most recent guidelines say not to use the Revision > field anyway (as it will be phased out soon) and say that only > packages not written specially for Debian shouldn't have a -<revision> > component in their Version field.
I'm not religious on this issue, but I'd prefer it if a revision (or, equivalently, a hyphen-delimited revision suffix of the version number) were a required part of the package name. Authors of packages which originate under debian could arbitrarily choose 0 or 1 for the revision for debian packaging purposes. I don't see any advantage in introducing an unnecessary irregularity into the package naming and versioning scheme over this. >[...] > * There is little point trying to keep our filenames completely > consistent with the upstream maintainers'. In fact, upstream > maintainers' filenames are frequently very inconsistent across > packages, and we want to present a consistent filename format for > neatness. However, keeping package names consistent with the upstream maintainer's naming is not prohibited by the Guidelines. In fact, I suspect that this practice is more the rule than the exception. >[...] > * Revisions are allowed to contain `.' characters. See the packaging > guidelines. Ouch!!!! -- but correct. The latest Guidelines file I have says, in part: <debian_revision> indicates which `debianisation' this is (this should usually be a plain number, or perhaps two numbers separated by a full stop). I say "Ouch" because this makes parsing filenames much more difficult than would be the case if the '.' character were not allowed in the Revision field. No packages currently seem to be using a full stop ('.') in the REVISION field. I suggest that the section of the Guidelines having to do with control file fields used for package naming be changed to read something like the following: ------------------------------------------------------------------------ [...] The required fields in the control file are the following: PACKAGE: <Short name of package> VERSION: <Original version number `original_version'> REVISION: <Debian package revision number `debian_revision'> MAINTAINER: <Name and e-mail address of package maintainer> DESCRIPTION: <Description of package> The contents of the PACKAGE, VERSION, and REVISION fields will be used to generate filenames by the installation tools, and therefore must not contain any embedded whitespace or slashes. The PACKAGE field is a short name for the package. A common naming convention for packages which generate a single binary package is to use the short package name used by the upstream oackage maintainer naming his source package in this field as the binary package name. The VERSION field should be the version number of the package. For most packages which are not written specifically for Debian, this should be the version number of the upstream source package. In addition to the restriction mentioned previously that this field contain no embedded slashes or whitespace, this field may contain no hyphen ('-') characters. Upstream version numbers containing slashes, whitespace, or hyphen characters must be revised to eliminate these characters. A suggested convention for version number revision is to transliterate forbidden characters to underscores ('_'). (e.g., debian binary packages built from an upstream source package with a version number of 1.2-3.4/5 might use a version number of 1.2_3.4_5 in their control files). The REVISION field identifies one specific revision of a debian package from among perhaps several package revisions built from the same version of an upstream source package. In addition to the restriction mentioned previously that this field contain no embedded slashes or whitespace, this may contain no full-stop ('.') characters. A common convention is for this field to contain contain a numeric or alphanumeric revision number, and which is incremented with successive package revisions. [... MAINTAINER and DESCRIPTION info ...] The REVISION field is not strictly required to be present as a separate control file field. It is acceptable to instead express the REVISION information as a hyphen-delimited suffix of the VERSION field. THe control field field specification: VERSION: 1.2-3 if presented without a REVISION field is equivalent to: VERSION: 1.2 REVISION: 3 [...] ------------------------------------------------------------------------