Hello Adam,
On Wed, Mar 28 2018, Adam Borowski wrote:
> Here's my proposed wording:
Thank you for working on this.
> .----
> §3.2.2. Versions must be unique
"Uniqueness of version numbers" would be more fitting with Policy's
tone.
And versions are unique by definition :) It's version numbers that are
the problem here.
> Because of a quirk of file naming, version numbers that are identical
> save for epoch cause problems, and thus must not be used.
This sentence is quite confusing. It seems to suggest that the whole
reason version numbers should not be reused is because of a quirk in
file naming, which is false.
Further, if we're going to mention the quirk in file naming, we should
say what that quirk is, or people reading won't understand what's going
on.
Finally, you haven't given a sense to the verb phrase "use version
numbers that are identical" -- use them for what?
Suggested replacement:
The part of the version number after the epoch must not be reused for a
version of the package with different contents, even if the version
of the package previously using that part of the version number is
no longer present in any archive suites.
Epochs are not included in the names of the files that compose
source packages, or in the filenames of binary packages, so reusing
a version number, even if the epoch differs, results in identically
named files with different contents. This causes various problems.
> In such case
I think we should say what the case is.
> you may bump the Debian revision (it doesn't need to
> start at 1 or be consecutive) or append a tag.
Policy doesn't define "tags" in version numbers so might be good to give
an example (possibly using the +really convention?).
> In these three namespaces: source, upstream (.orig), and binary, a
> combination of package name:version-without-epoch must never be reused
> once a package has been accepted into the archive, even after a
> release the package belonged to has been obsoleted.
I think the quoted sentence is obsoleted by what I wrote above, so can
be deleted. But let me know what you think.
> WRT doing policy first before DAK/etc implementation: a maintainer in
> #887740 refused to make a version before such a requirement has been agreed
> upon -- thus, it'd be good to provide guidelines even before they're
> enforced with code.
Just to note that since Policy is about the contents of source and
binary packages, not about the behaviour of dak, this is a case where
our convention of changing the archive before changing Policy does not
apply, and so existing convention does not determine which should happen
first.
--
Sean Whitton
Attachment:
signature.asc
Description: PGP signature