Whether Revisions should be required

[Ian Jackson <ian@chiark.chu.cam.ac.uk>]

Here are some of the arguments I've seen recently in favour of making
Revisions required:

David Silber:
> 1)  Stylistic preference (based on reason #2).
> 2)  Consistency.  [...]

I'll treat these as one objection.

I think that it is less consistent to provide a `Debian revision'
number for something that has no Debian revisions, because it is less
consistent with reality.

Note that in a world where the Debian revision number is folded into
the Version field it is less inconsistent for some packages not to
have one - it's a slight difference in version number format (which is
fairly inconsistent anyway, since it depends on upstream packaging)
rather than the presence or absence of a particular field.

Manoj Srivastava:
>         IMHO, the added consistency and ease of parsing of the package
>  name (no, I don't know yet why I need that, but I'd rather have an
>  option) are desirable, and a strong argument to the contrary is
>  needed _not_ to require the revision field.

As I've pointed out, it doesn't provided added ease of parsing of
filenames (which I presume is what you mean by `package name'),
because filenames are not in general parseable anyway.

Carl Streeter:
> I don't know.  On the one hand, it seems like it would be easier to identify
> "debian only" packages with -0, and "upstream maintainer maintains debian
> package" as generally having -1.

It's even easier when Debian-only packages have no revision at all, as
their version numbers wouldn't contain a hyphen at all (in general the
last hyphen separates the revision from the version).  This makes more
sense than arbitrarily using a code like `0'.

Bill Mitchell:
> On Wed, 6 Mar 1996, Ian Jackson wrote:
> > (a) dchanges does not need to parse the package name, version and
> > revision out of the filename(s) - it can look inside the .deb file
> > which it is be supplied with to determine this information.
> 
> True, if a .deb file is supplied.

If no .deb file is supplied then a Debian package is not being
released.  Something else Debian-related may be, but it doesn't make
sense to use our semi-automated upload scheme for things that don't
fit into it.  What are the semantics of (say) the Package field in the
release announcement when there is no Debian package involved ?

Also, I hope that dchanges checks to see that all the components
(currently .deb, .tar.gz and perhaps .diff.gz) of a package upload are
present -- and, of course, if it does then it won't succeed without a
.deb file anyway.  If there is an option to allow the special case
where the .deb file is lacking then there could (and IMO should) be
options to supply the information that dchanges could (IMO should)
otherwise get from the control file(s) of the binary package(s) being
announced.

... more Bill Mitchell:
>   dchanges doesn't currently work this
> way, but I guess I could rewrite it (yet again) to work that way.

I'm sorry to cause you extra work, but IMO if something has been
implemented incorrectly (which it seems dchanges has, at least
according to current specifications) then it should be changed.

... yet more Bill Mitchell:
> Hyphens in the upstream version number are required to be transliterated
> by the source package maintainer to some other character (underline 
> suggested).

This is not the case - ie, our packaging guidelines do not require any
such thing and have never done so.  If you mean `*would* be required
to be [for dchanges to work by parsing the filename]' then your
statement is true, but IMO dchanges should not work that way.

As you can see, I don't find these arguments particularly convincing.
(I've not answered all the messages which have been posted, because
many were repeated arguments, &c).

As I said earlier, I'd like to come to some kind of consensus.

Ian.