file naming convention for debian package files (was: Re: dselect FTP method ...)
Ian Jackson <ian@chiark.chu.cam.ac.uk> 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
[...]
------------------------------------------------------------------------
Reply to: