Bug#248618: Section 3.2.1 encourages use of epochs

Robert Millan · External Since: Dec 24, 2004 Posts: 293

Package: debian-policy
Version: 3.6.1.0
Severity: normal

The following text may be read in section 3.2.1:

To prevent having to use epochs for every new upstream version, the
version number should be changed to the following format in such
cases: "19960501", "19961224". It is up to the maintainer whether
he/she wants to bother the upstream maintainer to change the version
numbers upstream, too.

Note that other version formats based on dates which are parsed
correctly by the package management system should not be changed.

Native Debian packages (i.e., packages which have been written
especially for Debian) whose version numbers include dates should
always use the "YYYYMMDD" format.

Ironicaly, using the "YYYYMMDD" scheme grants us an epoch whenever upstream
decides to use a normal version number. I propose the following scheme
instead:

"0.0.0+YYYYMMDD[.X]" for snapshots without a previous release.
"A.B.C+YYYYMMDD[.X]" for snapshots after release "A.B.C".

(where optional .X is an unsigned integer)

It should be also noted that many programs violate the versioning scheme
(both current and my proposed one) by adding the "cvs" string to the version
number (e.g. "A.B.C+cvsYYYYMMDD"). When upstream decides to migrate to another
RCS, this could lead to an epoch:

"A.B.C+cvsYYYYMMDD" -> "A.B.C+svnYYYYMMDD" (ok)
"A.B.C+cvsYYYYMMDD" -> "1:A.B.C+archYYYYMMDD" (bad)

This is already a violation, but I propose that Policy lists it explicitly
as such to avoid errors.

-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.26-1-k7
Locale: LANG=C, LC_CTYPE=C

-- no debconf information

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Robert Millan · External Since: May 11, 2004 Posts: 10

On Wed, May 12, 2004 at 03:02:14PM +0200, Jeroen van Wolffelaar wrote:
> On Wed, May 12, 2004 at 02:15:29PM +0200, Robert Millan wrote:
> > Ironicaly, using the "YYYYMMDD" scheme grants us an epoch whenever upstream
> > decides to use a normal version number. I propose the following scheme
> > instead:
> >
> > "0.0.0+YYYYMMDD[.X]" for snapshots without a previous release.
> > "A.B.C+YYYYMMDD[.X]" for snapshots after release "A.B.C".
> >
> > (where optional .X is an unsigned integer)
>
> What is wrong with an epoch? I find '0.0.0+20040512' quite ugly.

Both are ugly, but the latter will be fixed and an epoch is for ever. I
hate epochs. Bugs can be fixed but if you get an epoch it'll always be your
dead weight.

> Good point when there is no actual version, but if there is, I see no
> real problem. Change in VCS don't happen often, and it emphasises the
> fact it is an unstable, unreleased version.
>
> But a different identification, that isn't VCS-specific, like
> 'unreleased20040512' or 'trunk20040512' might be preferable (in the
> latter case it is a bit specific though...). I think the current
> practice is usually okay in this regard, it cannot hurt to be a bit more
> verbose in policy about this.

Either is fine for me. But being VCS-specific is not as it still may generate
an epoch.

--
Robert Millan

"[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work."

-- J.R.R.T., Ainulindale (Silmarillion)

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org

Robert Millan · External Since: May 11, 2004 Posts: 10

On Wed, May 12, 2004 at 03:39:59PM +0200, Jeroen van Wolffelaar wrote:
> >
> > Both are ugly, but the latter will be fixed and an epoch is for ever. I
> > hate epochs. Bugs can be fixed but if you get an epoch it'll always be your
> > dead weight.
>
> I think you're being way too emotional over version numbers Smile

.

Uhm.. well I'm just a bit picky on some things :>

> What if you upload a new upstream, but it is too broken yet, and you
> want to downgrade in Debian? You need an epoch. Or if you simply make a
> mistake? Or a NMU uploads a new upstream version, or a broken version,
> by mistake? It happens.

I would make it "newversion+oldversion". Similar things are done for alpha
or prealpha packages, e.g. "1.2+1.3pre3".

> One only should take care to not choose a version system that will
> require an epoch increase every time.

Well, if we can avoid it without any payload, why not do it?

--
Robert Millan

"[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work."

-- J.R.R.T., Ainulindale (Silmarillion)

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Bill Allombert · External Since: Nov 12, 2004 Posts: 299

On Fri, Jun 11, 2004 at 12:39:25AM +0200, Jeroen van Wolffelaar wrote:
> On Wed, May 12, 2004 at 03:54:46PM +0200, Robert Millan wrote:
> > On Wed, May 12, 2004 at 03:39:59PM +0200, Jeroen van Wolffelaar wrote:
> > > What if you upload a new upstream, but it is too broken yet, and you
> > > want to downgrade in Debian? You need an epoch. Or if you simply make a
> > > mistake? Or a NMU uploads a new upstream version, or a broken version,
> > > by mistake? It happens.
> >
> > I would make it "newversion+oldversion". Similar things are done for alpha
> > or prealpha packages, e.g. "1.2+1.3pre3".
> >
> > > One only should take care to not choose a version system that will
> > > require an epoch increase every time.
> >
> > Well, if we can avoid it without any payload, why not do it?
>
> The payload is obfuscated, hacked version numbers, newversion+oldversion
> is very confusing, especially if the package isn't at all in
> 'newversion'. You sure must admit that 'newversion+oldversion' is a hack
> around the version compare function...
>
> Epoch is the solution for that.

Epoch suffers from the nasty bug of not being written in the package
name. For example the file name of the .deb for gcc 4:3.3.3-3 is
gcc_3.3.3-3_i386.deb

This can be very confusing, especially when used for downgrading the
upstrream version. At worse you will end up with two packages with the
same name, which is not allowed.

So using newversion+oldversion is more reliable and cause less trouble.

Cheers,
--
Bill.

Imagine a large red swirl here.

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Bill Allombert · External Since: Nov 12, 2004 Posts: 299

On Fri, Jun 11, 2004 at 11:48:16AM +0200, Jeroen van Wolffelaar wrote:
> On Fri, Jun 11, 2004 at 09:19:25AM +0200, Bill Allombert wrote:
> > On Fri, Jun 11, 2004 at 12:39:25AM +0200, Jeroen van Wolffelaar wrote:
> > > On Wed, May 12, 2004 at 03:54:46PM +0200, Robert Millan wrote:
> > > > On Wed, May 12, 2004 at 03:39:59PM +0200, Jeroen van Wolffelaar wrote:
> > > > > What if you upload a new upstream, but it is too broken yet, and you
> > > > > want to downgrade in Debian? You need an epoch. Or if you simply make a
> > > > > mistake? Or a NMU uploads a new upstream version, or a broken version,
> > > > > by mistake? It happens.
> > > >
> > > > I would make it "newversion+oldversion". Similar things are done for alpha
> > > > or prealpha packages, e.g. "1.2+1.3pre3".
> > > >
> > > > > One only should take care to not choose a version system that will
> > > > > require an epoch increase every time.
> > > >
> > > > Well, if we can avoid it without any payload, why not do it?
> > >
> > > The payload is obfuscated, hacked version numbers, newversion+oldversion
> > > is very confusing, especially if the package isn't at all in
> > > 'newversion'. You sure must admit that 'newversion+oldversion' is a hack
> > > around the version compare function...
> > >
> > > Epoch is the solution for that.
> >
> > Epoch suffers from the nasty bug of not being written in the package
> > name. For example the file name of the .deb for gcc 4:3.3.3-3 is
> > gcc_3.3.3-3_i386.deb
> >
> > This can be very confusing, especially when used for downgrading the
> > upstrream version. At worse you will end up with two packages with the
> > same name, which is not allowed.
> >
> > So using newversion+oldversion is more reliable and cause less trouble.
>
> So because of some bug/feature (I'm not yet sure which one it is),
> rather than having the bug fixed, you want to abolish the feature called
> 'epoch'? Interesting...

I didn't made such claims, just pointing out some facts that are
relevant to the case at end.

Beside this bug is reported to debian-policy which is supposed to
document current practice and the current practice is that epoch
exhibits the above mentionned behaviour.

Cheers,
--
Bill.

Imagine a large red swirl here.

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Debian Bug Tracking Syste · External Since: Jul 07, 2005 Posts: 4166

Your message dated Fri, 25 Jun 2004 17:47:03 -0400
with message-id
and subject line Bug#248618: fixed in debian-policy 3.6.1.1
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--------------------------------------
Received: (at submit) by bugs.debian.org; 12 May 2004 12:21:18 +0000
>From rmh.TakeThisOut@khazad.dyndns.org Wed May 12 05:21:18 2004
Return-path:
Received: from 86.red-80-24-13.pooles.rima-tde.net (khazad.dyndns.org) [80.24.13.86]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1BNsjY-0000d3-00; Wed, 12 May 2004 05:21:17 -0700
Received: from rmh by khazad.dyndns.org with local (Exim 3.36 #1 (Debian))
id 1BNse5-00067D-00; Wed, 12 May 2004 14:15:33 +0200
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Robert Millan
To: Debian Bug Tracking System
Subject: Section 3.2.1 encourages use of epochs
X-Mailer: reportbug 2.58
Date: Wed, 12 May 2004 14:15:29 +0200
Message-Id:
Sender:
Delivered-To: submit.TakeThisOut@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-7.0 required=4.0 tests=BAYES_00,HAS_PACKAGE
autolearn=no version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level:
X-CrossAssassin-Score: 1

Package: debian-policy
Version: 3.6.1.0
Severity: normal

The following text may be read in section 3.2.1:

To prevent having to use epochs for every new upstream version, the
version number should be changed to the following format in such
cases: "19960501", "19961224". It is up to the maintainer whether
he/she wants to bother the upstream maintainer to change the version
numbers upstream, too.

Note that other version formats based on dates which are parsed
correctly by the package management system should not be changed.

Native Debian packages (i.e., packages which have been written
especially for Debian) whose version numbers include dates should
always use the "YYYYMMDD" format.

Ironicaly, using the "YYYYMMDD" scheme grants us an epoch whenever upstream
decides to use a normal version number. I propose the following scheme
instead:

"0.0.0+YYYYMMDD[.X]" for snapshots without a previous release.
"A.B.C+YYYYMMDD[.X]" for snapshots after release "A.B.C".

(where optional .X is an unsigned integer)

It should be also noted that many programs violate the versioning scheme
(both current and my proposed one) by adding the "cvs" string to the version
number (e.g. "A.B.C+cvsYYYYMMDD"). When upstream decides to migrate to another
RCS, this could lead to an epoch:

"A.B.C+cvsYYYYMMDD" -> "A.B.C+svnYYYYMMDD" (ok)
"A.B.C+cvsYYYYMMDD" -> "1:A.B.C+archYYYYMMDD" (bad)

This is already a violation, but I propose that Policy lists it explicitly
as such to avoid errors.

-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.26-1-k7
Locale: LANG=C, LC_CTYPE=C

-- no debconf information

---------------------------------------
Received: (at 248618-close) by bugs.debian.org; 25 Jun 2004 21:53:35 +0000
>From katie.TakeThisOut@ftp-master.debian.org Fri Jun 25 14:53:35 2004
Return-path:
Received: from newraff.debian.org [208.185.25.31] (mail)
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1Bdydb-00071n-00; Fri, 25 Jun 2004 14:53:35 -0700
Received: from katie by newraff.debian.org with local (Exim 3.35 1 (Debian))
id 1BdyXH-0001Qm-00; Fri, 25 Jun 2004 17:47:03 -0400
From: Manoj Srivastava
To: 248618-close.TakeThisOut@bugs.debian.org
X-Katie: $Revision: 1.51 $
Subject: Bug#248618: fixed in debian-policy 3.6.1.1
Message-Id:
Sender: Archive Administrator
Date: Fri, 25 Jun 2004 17:47:03 -0400
Delivered-To: 248618-close.TakeThisOut@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level:
X-CrossAssassin-Score: 18

Source: debian-policy
Source-Version: 3.6.1.1

We believe that the bug you reported is fixed in the latest version of
debian-policy, which is due to be installed in the Debian FTP archive:

debian-policy_3.6.1.1.dsc
to pool/main/d/debian-policy/debian-policy_3.6.1.1.dsc
debian-policy_3.6.1.1.tar.gz
to pool/main/d/debian-policy/debian-policy_3.6.1.1.tar.gz
debian-policy_3.6.1.1_all.deb
to pool/main/d/debian-policy/debian-policy_3.6.1.1_all.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 248618.TakeThisOut@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Manoj Srivastava (supplier of updated debian-policy package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster.TakeThisOut@debian.org)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Fri, 25 Jun 2004 16:07:38 -0500
Source: debian-policy
Binary: debian-policy
Architecture: source all
Version: 3.6.1.1
Distribution: unstable
Urgency: low
Maintainer: Debian Policy List
Changed-By: Manoj Srivastava
Description:
debian-policy - Debian Policy Manual and related documents
Closes: 50565 51832 68827 70742 75508 79210 185943 202054 209855 212153 215524 215558 218530 227762 232364 235484 236614 237049 238958 241683 244969 247143 247761 248618 248786 248788 252086 252392 253324
Changes:
debian-policy (3.6.1.1) unstable; urgency=low
.
Manoj:
* [AMENDMENT 15/09/2003] Move documentation of behavior of ancient dpkg
in 6.6 to a footnote. closes: Bug#209855
* Fix the outdated link for the mime subpolicy. closes: Bug#212153
* Fix a missing comma in the list of sections closes: Bug#215524
* Fix spelling of sysv-rc closes: Bug#215558
* [AMENDMENT 28/03/2004] ${perl:Depends} documentation
incomplete. Added an informative foot note stating that dependencies
caused by versioned uses and on separately packaged modules are not
included in this variable and must be explicitly included.
closes: Bug#202054
* Clarified that section 3.2.1 refers to the date based postion of the
version number, if not already clear from the context. This allows
developers leeway in selecting date based version numbers for their
packages, without loosing the advantages of the format specified in
this section. closes: Bug#248618
* Bug fix: "Broken link to virtual-package-names-list.txt in section
3.6", thanks to Carlos O'Donell (Closes: #248786).
* Bug fix: "Broken link to debconf_specification.txt.gz in section
3.10.1 of the Debian Policy manual.", thanks to Carlos O'Donell and
Scott C.MacCallum (Closes: #248788, 247761).
* Bug fix: "missing commas in subsections list", thanks to Filippo
Giunchedi (Closes: #236614).
* Bug fix: "debian-policy: policy-process, broken URL", thanks to Manoj
Srivastava (Closes: #244969).
* Bug fix: "bad reference to debconf-devel( Cool

has to be (7)", thanks to
Kevin Price (Closes: #247143).
* Bug fix: "debian-policy: Small wording change", thanks to Mike Paul
(Closes: #252392).
* Bug fix: "debian-policy: broken URL: CSH Programming Considered
Harmful", thanks to Steven Augart (Closes: #253324).
* Bug fix: "New virtual package: cron-daemon", thanks to Adam Byrtek
(Closes: #252086).
Josip:
* Fixed detection of invoke-rc.d's existence, closes: #218530.
* Generalized the dpkg-shlibdeps example and added a current example in a
footnote, set proper section ids and linked the d-sd section better,
closes: #50565.
* Clarified the section about the Architecture field and added footnotes
to indicate recommended actions, closes: #51832.
* Updated PGP references, closes: #68827.
* Linked f-Format in the list of fields of the .dsc file, not mandatory
according to my skimming of dpkg-source, closes: #70742.
* Fixed the command line required to output the copyright file,
closes: #75508.
* Removed the long obsolete notion of specific directory names within
source tarballs, closes: #79210.
Andi:
* sgml-dtd was moved, fix FTBFS. Closes: #241683
* fix link to WM specification. Closes: #235484
* manpage -> man page. Closes: #232364, #238958
* language adjustment. Closes: #227762
* added virtual packages stardict-dictionary, inetd-superserver.
Closes: #185943, #237049
Files:
becef00dbb8a6ddd8ba873b451e71abc 821 doc optional debian-policy_3.6.1.1.dsc
f5f8885e1ba92af21040f13c8e170bc9 1792188 doc optional debian-policy_3.6.1.1.tar.gz
ad93bc21329ec94481a1b26c313b1984 1185284 doc optional debian-policy_3.6.1.1_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA3Jo+Ibrau78kQkwRAhRqAJ40u+DsgbGb+JZelPoo8L1WPvuefACgq4mr
fJpgxeWomof+4OIiXy1PojQ=
=TrRy
-----END PGP SIGNATURE-----

--
To UNSUBSCRIBE, email to debian-policy-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org