Re: Versions and revisions

[Bill Mitchell <mitchell@mdd.comm.mot.com>]

Ian J:
+ The removal of the revision field was discussed and agreed in July.  I
+ note in particular that Bill Mitchell seemed quite happy with the
+ idea, apart from one issue (arguments to maintainer scripts) that I
+ answered.

I recall your proposing this, and the discussion period which followed.
I don't recall that there was major comment one way or the other on
the issue at the time (there may have been -- I don't recall any).

Out of curiosity, I checked the debian-devel list logs on the ftp
site, but they don't seem to go back quite this far.  As for my being
"quite happy" with it, I do remember being vaguely uncomfortable with
it, but I think I refrained from offering an objection because I didn't
have any specific substantive issue on which to base an objection and/or
because there were other things going on at the time with which I was
more concerned.  Last July I was in the middle of a major change in my
real-life work responsibilities, and that probably defocused me from
debian for a while.

Bottom line:  I'm pretty sure that I offered no objection, and I may
even have said that I had no objection to offer.  "quite happy"
overstates my feeling about the change, but I may have given that
impression to the list.

Ian, continuing:
[...]  I have better things to do than
+ field a flamewar about a decision taken 7 months ago.

Me too,  I didn't intend to start a flamewar.

+ Furthermore, I object to the following:
+ 
+ Bill Mitchell suggests that we reinstate the revision field, and says:
+ > However, that probably makes too much sense for us to do it.
+ 
+ This kind of snide comment is unhelpful, IMO.

Snide:  bogus, sly, malicious.

I honestly don't believe the comment was bogus, but that's a subjective
value judgement.  I didn't intend it as sly or malicious.  It was a 
throw-off comment and reflected my feeling of frustration about this.
It was made in a rushed response to something, possibly something you 
posted, and came across stronger than I intended. That's my fault.  I 
apologize.

+ I find it especially galling that he now has the temerity to say that
+ reversing the earlier decision `makes too much sense for us to do it'
+ when he didn't present his objections to the decision when it was
+ being made.

Galling:  irritating, troublesome, annoying

Admitted.  Again, it came across stronger than I intended, and that's
my fault.  Apologies offered.

Ian, from a separate posting addressing the issue of requiring a
revision field in package file names::
+ 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. [...]

I'd disagree.  Eye of the beholder, I guess.

Ian:
+ 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.

I think Manoj meant ease of parsing (or, possibly, ability to parse)
the package name out of the name of a file associated with the package
(possibly not the .deb file).  That's what dchanges looses without a
required revision field to regularize the package file naming format
so that the components are parseable.

Ian:
+ 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'.

Is it useful to be able to recognize Debian-only packages by inspecting
their package file names?  If this is useful, is it useful to be
able to do this mechanically?

I don't know the answer to the first question.  If the answer is "no",
the second doesn't arise.

If the answer to both questions is "yes", a package file naming standard
which provides parseable filenames is more useful than one which does not.

+ 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 ?

What the dchanges package is concerned with is producing changes files
as a medium for interaction with the package maintainer, either personally
or via automated scripts which he may provide to process changes files.

The changes files needn't necessarily involve upload of .deb files or
immediate release of any package files.  I was trying to make dchanges
pretty general, not limited to its immediately intended uses.  I was
also trying to make it able to infer much of the information needed
to prepare the changes file (e.g., the name of the package involved)
from filenames suppied to it, so as not to burden the package maintainer
with explicitly supplying items of information which could be inferred,
and so as to lessen the possibility of unintended conflicting information
from such sources as a possible unrecognized typo.

+ 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.

There is a mechanism for explicitly supplying (and possibly mistyping)
the package name.  dchanges, (especially the new, unreleased, dchanges)
tries to get such information from package file names where it can.

+ ... 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.

As I said earlier, this was discussed at some length a month or so ago,
and a consensus reached.  I don't recall strong objections from you on
this issue, or a flat refusal to pick up the consensus position and
incorporate it into the guidelines.  I assumed that the consensus position
would have been picked up in the guidelines.  Bad assumption.

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

Me too.  In the meantime, I was quite serious a day or two back when
I offered the dchanges package to anyone who wished to pick it up.
I too would rather spend more time doing useful work and less time
in discussions which don't seem to be going anywhere.

mitchell@mdd.comm.mot.com (Bill Mitchell)