RE: libc6_2.0.7 release notes...
I found no mention in the web site's policy manual of version numbering.
Since it has made the transition to the policy list, I am advocating
reviewing the policy (in the packaging manual) for possible changes to
solve future problems caused by the packaging of pre-release upstream
versions.
If policy is not created/changed to handle this, we are doomed to revisit
it.
>From the *packaging manual* on
http://www.debian.org/doc/packaging-manuals/packaging.html/ch-versions.html
(I found no mention in the policy manual of version numbering.)
dpkg imposes an ordering on version numbers, so that it can tell whether
packages are being up- or downgraded and so that dselect can tell whether
a package it finds available is newer than the one installed on the
system. The version number format has the most significant parts (as far
as comparison is concerned) at the beginning.
[skip epoch and upstream sections]
debian-revision
This part of the version represents the version of the modifications
that were made to the package to make it a Debian binary package. It
is in the same format as the upstream-version and dpkg compares it in
the same way.
It is optional; if it isn't present then the upstream-version may not
contain a hyphen. This format represents the case where a piece of
software was written specifically to be turned into a Debian binary
package, and so there is only one `debianization' of it and therefore
no revision indication is required.
It is conventional to restart the debian-revision at 1 each time the
upstream-version is increased.
dpkg will break the upstream-version and debian-revision apart at
the last hyphen in the string. The absence of a debian-revision
compares earlier than the presence of one (but note that the debian-
revision is the least significant part of the version number).
The debian-revision may contain only alphanumerics and the characters
+ and . (plus and full stop).
Note there is no mention of non-maintainer releases. Granted the proposal
I advocated would violate the current letter of the packaging manual by
incrementing the debian version number for non-maintainer releases. If
pressed I might claim the software was made into a debian package, then
the debian package was changed to include patches prior to a full
upstream release.
As many have pointed out, epochs could also be used to 'solve' this problem,
but I don't agree with that solution for *this* problem (pre-release
versions).
I think we need a way to uniformly and clearly distinguish pre-release
software
from release software, and that is what I proposed.
Pat
(who still has problems telling left from right)
> -----Original Message-----
> From: Scott K. Ellis [mailto:storm@gate.net]
> Sent: Thursday, June 25, 1998 3:22 PM
> To: Dale Scheetz; debian-policy@lists.debian.org
> Subject: Re: libc6_2.0.7 release notes...
>
>
> On Thu, Jun 25, 1998 at 02:09:43PM -0400, Dale Scheetz wrote:
> > On Thu, 25 Jun 1998, Jules Bean wrote:
> >
> > > Someone suggested this earlier in the discussion, and someone
> else pointed
> > > out that this is clearly against policy, since anything after
> the '-' should
> > > reflect debian-specific packaging changes, not upstream changes.
> > >
> > Then I would argue that the policy statement is self
> contradictory. The -0
> > and -1 suffixes create (and declare) those releases to be source change
> > releases, which are, obviously, upstream changes.
>
> That's odd. It was my understanding that a -0 release simply indicated a
> non-maintainer release of a new upstream source. I'm not aware
> of any place
> in the policy manuals that says that -0 and -1 might be different
> sources.
> I know dpkg-buildpackage considers either one grounds for a source upload,
> but I don't see where it is mentioned (or obvious) that they are different
> sources. dpkg-buildpackage just can't deduce that there might have been
> a -0 release, so it must assume that -1 is the first release.
>
> I'm still really vague on what REAL technical objection has been raised to
> actually using (oh, horror!) epochs. Yes, it will remain in the version
> number "forever". So what? Who cares? If the epoch reaches 50, who is
> going to notice and care? The reason we use the upstream version
> numbers is
> for recognition. If they don't fit, we use epochs and be done
> with it. The
> version numbers are recognisable in the filenames, and dpkg knows which
> comes first. I see that as a good thing.
>
> --
> Scott K. Ellis <storm@gate.net>
>
>
> --
> To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
>
>
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: