Re: Debian part of a version number when epoch is bumped

[Ian Jackson]

Christian T. Steigies writes ("Re: Debian part of a version number when epoch 
is bumped"):
> On Mon, Apr 02, 2018 at 08:41:00PM +0100, Simon McVittie wrote:
> > [...]  So what I'd advise *now* would be to increase the revision
> > to 12 and carry on from there.
> 
> This has been addressed by policy now, does you recommendation still hold?

I see no relevant difference between the views expressed by Simon in
his email, and the statement now codified in policy.

I agree with the policy and IMO Simon's recommendations are good.

> I understand the explanation for source and binary package, but I wonder if
> I have the right interpretation for the upstream source code:
> 
> https://www.debian.org/doc/debian-policy/#uniqueness-of-version-numbers
>   3.2.2. Uniqueness of version numbers
>   ...
>   Additionally, for non-native packages, the upstream version must not be
>   reused for different upstream source code, so that for each source package
>   name and upstream version number there exists exactly one original source
>   archive contents (see Files).
> 
> Since the intial upload was as native package, and the latest as non-native,
> this does not apply to moon-buggy and I can upload with revision 12 as you
> suggested?

I think this is correct, yes.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Debian part of a version number when epoch is bumped

[Christian T. Steigies]

On Mon, Apr 02, 2018 at 08:41:00PM +0100, Simon McVittie wrote:
> 
> A recap of what happened, for those who might have lost track:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887740#10
> > The old source package contained two tar
> > balls, the "real" tarball plus a separate one with patches (upstream wanted
> > things separate). The build script was, say, not optimal, and I also made
> > the mistake of uploading it as debian native package. By bumping the epoch
> > and repackaging from scratch, I tried to fix all the mistakes I had made a
> > long time ago.
> 
> The newest version of the old tar-in-tar packaging can be seen here:
> https://sources.debian.org/src/moon-buggy/1.0.51-11/
> 
> What I would personally have done *then*, from that starting point, would
> be to bump the version to 1.0.51+repack, or maybe 1.0.51+upstream if
> the new orig tarball was something that the upstream developer released,
> or something similar, then package and upload revision 1 of that. That
> would have been fine - no epoch needed.
> 
> However, because you previously maintained this as a native package,
> there has been no collision for the filename of the orig.tar.gz, because
> before the epoch was added there *was* no orig.tar.gz; and you've already
> paid the maintenance cost of having an epoch, so you might as well benefit
> from it. So what I'd advise *now* would be to increase the revision to 12
> and carry on from there.

This has been addressed by policy now, does you recommendation still hold?
I understand the explanation for source and binary package, but I wonder if
I have the right interpretation for the upstream source code:

https://www.debian.org/doc/debian-policy/#uniqueness-of-version-numbers
  3.2.2. Uniqueness of version numbers
  ...
  Additionally, for non-native packages, the upstream version must not be
  reused for different upstream source code, so that for each source package
  name and upstream version number there exists exactly one original source
  archive contents (see Files).

Since the intial upload was as native package, and the latest as non-native,
this does not apply to moon-buggy and I can upload with revision 12 as you
suggested?

thanks,
Christian

Re: Debian part of a version number when epoch is bumped

[James McCoy]

On Mon, Apr 02, 2018 at 11:01:30PM -0400, The Wanderer wrote:
> On 2018-04-02 at 15:41, Simon McVittie wrote:
> 
> > On Mon, 02 Apr 2018 at 20:30:54 +0200, Christian T. Steigies wrote:
> > 
> >> I don't understand why everybody is so afraid of an epoch, but ok.
> > 
> > It's a source of confusion (and confusing side-effects) that, once 
> > added, can never be removed, however many upstream releases might 
> > happen.
> 
> I thought that in theory, if the upstream version later increases to the
> point where it would sort above the with-an-epoch version (whether
> because it's a date-based version and new versions keep coming out all
> the way into the next millennium, or because the upstream version scheme
> changes again, or whatever else), the epoch could potentially be dropped
> without introducing issues. Is that wrong?

Yes.  There's an implicit 0 epoch in any version that doesn't have
an explicit epoch.  Therefore, it doesn't matter what contortions the
upstream version does.  Returning to an implicit 0 epoch would sort
lower than the previous explicit epoch.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Re: Debian part of a version number when epoch is bumped

[The Wanderer]

On 2018-04-02 at 15:41, Simon McVittie wrote:

> On Mon, 02 Apr 2018 at 20:30:54 +0200, Christian T. Steigies wrote:
> 
>> I don't understand why everybody is so afraid of an epoch, but ok.
> 
> It's a source of confusion (and confusing side-effects) that, once 
> added, can never be removed, however many upstream releases might 
> happen.

I thought that in theory, if the upstream version later increases to the
point where it would sort above the with-an-epoch version (whether
because it's a date-based version and new versions keep coming out all
the way into the next millennium, or because the upstream version scheme
changes again, or whatever else), the epoch could potentially be dropped
without introducing issues. Is that wrong?

If so, I'd be interested to see an example of a case where problems
would result, because while I can intellectually conceive of there being
such I so far haven't been able to think of any.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Debian part of a version number when epoch is bumped

[Simon McVittie]

On Mon, 02 Apr 2018 at 20:30:54 +0200, Christian T. Steigies wrote:
> I don't understand why everybody is so afraid of an epoch, but ok.

It's a source of confusion (and confusing side-effects) that, once added,
can never be removed, however many upstream releases might happen.

> On Fri, Mar 30, 2018 at 02:21:43PM +0300, Adrian Bunk wrote:
> > The second problem is about filename overlap after incorrect epoch usage.
> 
> So the epoch is not really part of the version number, it is just there for
> "sorting"?

Sort of. It appears in the form of the version number that's in most
places, but not in canonical filenames. Conceptually, it's part of the
Debian package version but not part of the upstream version.

> > What can be done for moon-buggy is to use a Debian revision that doesn't
> > result in filenames that are duplicates with pre-epoch packages.
> 
> So what should I have done intially and what should I do now?
>
> I should have uploaded the package as 1.0.51-12 even though I uploaded a
> (new) orig.tar.gz?

A recap of what happened, for those who might have lost track:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887740#10
> The old source package contained two tar
> balls, the "real" tarball plus a separate one with patches (upstream wanted
> things separate). The build script was, say, not optimal, and I also made
> the mistake of uploading it as debian native package. By bumping the epoch
> and repackaging from scratch, I tried to fix all the mistakes I had made a
> long time ago.

The newest version of the old tar-in-tar packaging can be seen here:
https://sources.debian.org/src/moon-buggy/1.0.51-11/

What I would personally have done *then*, from that starting point, would
be to bump the version to 1.0.51+repack, or maybe 1.0.51+upstream if
the new orig tarball was something that the upstream developer released,
or something similar, then package and upload revision 1 of that. That
would have been fine - no epoch needed.

However, because you previously maintained this as a native package,
there has been no collision for the filename of the orig.tar.gz, because
before the epoch was added there *was* no orig.tar.gz; and you've already
paid the maintenance cost of having an epoch, so you might as well benefit
from it. So what I'd advise *now* would be to increase the revision to 12
and carry on from there.

smcv

Re: Debian part of a version number when epoch is bumped

[Adrian Bunk]

On Mon, Apr 02, 2018 at 08:30:54PM +0200, Christian T. Steigies wrote:
> Moin,

Hi,

> On Fri, Mar 30, 2018 at 02:21:43PM +0300, Adrian Bunk wrote:
> > 
> > There are two problems here.
> > 
> > The first is the use of an epoch in a situation where it shouldn't be used.
> > 
> > The actual "trap" is when a maintainer used an epoch in such a situation.
> > 
> > Once introduced in a package an epoch cannot ever be undone, so all that 
> > can be done on that is to make it clearer that it is wrong to use an 
> > epoch in such cases.
> 
> I don't understand why everybody is so afraid of an epoch, but ok.

not really afraid. "optically not nice", "slightly confusing" and
"irreversible" are the words I would use.

> > The second problem is about filename overlap after incorrect epoch usage.
> 
> So the epoch is not really part of the version number, it is just there for
> "sorting"?

It is somehow part of the version number, but not in the filenames.

This is not a problem when an epoch is used for a change in the upstream 
version numbering scheme.

> > It is important to understand that this is only relevant for cases where 
> > an epoch was used where it shouldn't have been:
> > When an epoch is used as intended for a change in the upstream version 
> > numbering scheme (e.g. from 20171224 to 1.0), there is no overlap in
> > version numbers.
> > 
> > Launchpad gave an error on that, and this is better than the silent 
> > breakage in Debian of the assumption that no filename is ever used twice 
> > in Debian. I would consider it a bug in dak that it doesn't know about 
> > all versions and filenames that ever existed in Debian.
> 
> ok
>  
> > It would be wrong to document in Debian policy that skipping Debian 
> > revisions is required in such cases, since the only case where this
> > second problem can happen is when a maintainer used an epoch in a
> > situation where it shouldn't be used (first problem).[1]
> > 
> > For the future it should be documented better that using an epoch is 
> > wrong in such cases, but for past incorrect epoch usage all that can
> > be done is to limit the damage.
> 
> If this can't go into policy, then I hope it will go into the wiki or a
> packaging best-practices or so.
>  
> > Things that cannot be undone for moon-buggy:
> > - the epoch
> > - two files moon-buggy_1.0.51-1.dsc exist in Debian,
> >   with different contents [2]
> > 
> > What can be done for moon-buggy is to use a Debian revision that doesn't
> > result in filenames that are duplicates with pre-epoch packages.
> 
> So what should I have done intially and what should I do now?
> 
> I should have uploaded the package as 1.0.51-12 even though I uploaded a
> (new) orig.tar.gz?

Yes.

As far as I understand it a mistake happened back in 2006 when a new 
upstream version was uploaded as .tar.gz instead of .orig.tar.gz and
.diff.gz.

Correcting this mistake was correct, but it did not require an epoch.

> Now I should upload it as 1:1.0.51-12 and be done with it?

I don't see a reason for touching the 1:1.0.51-1 changelog entry,
files like moon-buggy_1.0.51-1.dsc or moon-buggy_1.0.51-1_amd64.deb
are no longer unique in the history of Debian and this cannot be
undone.

Uploading with a new changelog entry for 1:1.0.51-12 added on top
of the current 1:1.0.51-1 entry is the best option.

> No renaming of the orig.tar to 1.0.51+really1.0.51 neccessary?

This is not necessary, unless I miss something there was never before
a (different) moon-buggy_1.0.51.orig.tar.gz in Debian.

> thanks,
> Christian

Thanks
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Debian part of a version number when epoch is bumped

[Christian T. Steigies]

Moin,
On Fri, Mar 30, 2018 at 02:21:43PM +0300, Adrian Bunk wrote:
> 
> There are two problems here.
> 
> The first is the use of an epoch in a situation where it shouldn't be used.
> 
> The actual "trap" is when a maintainer used an epoch in such a situation.
> 
> Once introduced in a package an epoch cannot ever be undone, so all that 
> can be done on that is to make it clearer that it is wrong to use an 
> epoch in such cases.

I don't understand why everybody is so afraid of an epoch, but ok.

> The second problem is about filename overlap after incorrect epoch usage.

So the epoch is not really part of the version number, it is just there for
"sorting"?

> It is important to understand that this is only relevant for cases where 
> an epoch was used where it shouldn't have been:
> When an epoch is used as intended for a change in the upstream version 
> numbering scheme (e.g. from 20171224 to 1.0), there is no overlap in
> version numbers.
> 
> Launchpad gave an error on that, and this is better than the silent 
> breakage in Debian of the assumption that no filename is ever used twice 
> in Debian. I would consider it a bug in dak that it doesn't know about 
> all versions and filenames that ever existed in Debian.

ok
 
> It would be wrong to document in Debian policy that skipping Debian 
> revisions is required in such cases, since the only case where this
> second problem can happen is when a maintainer used an epoch in a
> situation where it shouldn't be used (first problem).[1]
> 
> For the future it should be documented better that using an epoch is 
> wrong in such cases, but for past incorrect epoch usage all that can
> be done is to limit the damage.

If this can't go into policy, then I hope it will go into the wiki or a
packaging best-practices or so.
 
> Things that cannot be undone for moon-buggy:
> - the epoch
> - two files moon-buggy_1.0.51-1.dsc exist in Debian,
>   with different contents [2]
> 
> What can be done for moon-buggy is to use a Debian revision that doesn't
> result in filenames that are duplicates with pre-epoch packages.

So what should I have done intially and what should I do now?

I should have uploaded the package as 1.0.51-12 even though I uploaded a
(new) orig.tar.gz?

Now I should upload it as 1:1.0.51-12 and be done with it?

No renaming of the orig.tar to 1.0.51+really1.0.51 neccessary?

thanks,
Christian

Re: Debian part of a version number when epoch is bumped

[Adrian Bunk]

On Wed, Mar 28, 2018 at 11:39:58PM +0200, Christian T. Steigies wrote:
>...
> You still have not convinced me that I did anything wrong with the version
> number and you keep ignoring my request for propper official documentation
> how to use and not use an epoch.  Maybe you all can read between the lines
> of the policy or just magically know how this was intended.  But I can not
> read your mind and I assume the majority of regular DDs can neither.  If it
> is incorrect to start with the debian revision from scratch after an epoch,
> please document it where a regular person can easily find it, especially if
> I am not the first person to fall into this trap.  I do not consider this
> bug report a suitable place for that (one of my packages has been used
> before in an Ubuntu packaging manual to show how to report a bug and nobody
> told me about this nor the "bug" until after years somebody finally reported
> the bug, is this the plan for moon-buggy and epochs?).
>...

There are two problems here.

The first is the use of an epoch in a situation where it shouldn't be used.

The actual "trap" is when a maintainer used an epoch in such a situation.

Once introduced in a package an epoch cannot ever be undone, so all that 
can be done on that is to make it clearer that it is wrong to use an 
epoch in such cases.

The second problem is about filename overlap after incorrect epoch usage.

It is important to understand that this is only relevant for cases where 
an epoch was used where it shouldn't have been:
When an epoch is used as intended for a change in the upstream version 
numbering scheme (e.g. from 20171224 to 1.0), there is no overlap in
version numbers.

Launchpad gave an error on that, and this is better than the silent 
breakage in Debian of the assumption that no filename is ever used twice 
in Debian. I would consider it a bug in dak that it doesn't know about 
all versions and filenames that ever existed in Debian.

It would be wrong to document in Debian policy that skipping Debian 
revisions is required in such cases, since the only case where this
second problem can happen is when a maintainer used an epoch in a
situation where it shouldn't be used (first problem).[1]

For the future it should be documented better that using an epoch is 
wrong in such cases, but for past incorrect epoch usage all that can
be done is to limit the damage.

Things that cannot be undone for moon-buggy:
- the epoch
- two files moon-buggy_1.0.51-1.dsc exist in Debian,
  with different contents [2]

What can be done for moon-buggy is to use a Debian revision that doesn't
result in filenames that are duplicates with pre-epoch packages.

> Christian

cu
Adrian

[1] in theory upstream could also create such a situation with frequent
changes in the versioning scheme, but that's not a problem in practice
[2] not in Ubuntu, where this problem was caught

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Debian part of a version number when epoch is bumped

[Simon McVittie]

On Wed, 28 Mar 2018 at 23:39:58 +0200, Christian T. Steigies wrote:
> propper official documentation how to use and not use an epoch

This appears to be in progress. In response to previous discussion of
this same issue, a dpkg maintainer wrote about this a few weeks ago:
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_What_are_version_epochs_and_why_and_when_are_they_needed.3F

Policy wording has also been proposed:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891216

> If it
> is incorrect to start with the debian revision from scratch after an epoch,
> please document it where a regular person can easily find it

This is also in progress:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881431

> I think the TC has more important problems to solve.

Jeremy's mention of the TC was in the context of wishing there was a
dispute-resolution mechanism less "heavy" than escalating to the TC,
so it seems you and Jeremy are in agreement there.

smcv

Re: Debian part of a version number when epoch is bumped

[Christian T. Steigies]

On Wed, Mar 28, 2018 at 04:16:19PM -0400, Jeremy Bicha wrote:
> On Mon, Feb 5, 2018 at 11:06 AM, Mattia Rizzolo  wrote:
> > Please don't consider the Debian Policy like a stick.  Or a all-kwowing
> > never-wrong oracle.
> 
> Well the maintainer refuses to make the minor change I requested. See
> the latest comments at
> https://bugs.debian.org/887740
> 
> I wish Debian had some form of informal conflict resolution besides
> the Tech Committee.

I am really amazed that you are making such a big deal about this package. 

You still have not convinced me that I did anything wrong with the version
number and you keep ignoring my request for propper official documentation
how to use and not use an epoch.  Maybe you all can read between the lines
of the policy or just magically know how this was intended.  But I can not
read your mind and I assume the majority of regular DDs can neither.  If it
is incorrect to start with the debian revision from scratch after an epoch,
please document it where a regular person can easily find it, especially if
I am not the first person to fall into this trap.  I do not consider this
bug report a suitable place for that (one of my packages has been used
before in an Ubuntu packaging manual to show how to report a bug and nobody
told me about this nor the "bug" until after years somebody finally reported
the bug, is this the plan for moon-buggy and epochs?).

I think the TC has more important problems to solve.  If you want to NMU the
package, go ahead.  I am not going to upload it with a version number which
I think is wrong, but I am not stopping you if you want to do that upload. 

Or we just drop it from Debian, upstream development has stopped years ago.
But that does not fix the problem with lacking documentation...

Christian

Re: Debian part of a version number when epoch is bumped

[Mattia Rizzolo]

On Wed, Mar 28, 2018 at 04:16:19PM -0400, Jeremy Bicha wrote:
> On Mon, Feb 5, 2018 at 11:06 AM, Mattia Rizzolo  wrote:
> > Please don't consider the Debian Policy like a stick.  Or a all-kwowing
> > never-wrong oracle.
> 
> Well the maintainer refuses to make the minor change I requested. See
> the latest comments at
> https://bugs.debian.org/887740

Right.
Ultimately, in Debian the maintianer of a package decides what to do to
that package.  If a maintainer refuse to land a change you are asking,
and you fail to "sell" your change, that it: that change won't be
applied, period.

> I wish Debian had some form of informal conflict resolution besides
> the Tech Committee.

As Chris noted, one of the (informal?) jobs of the DPL is to facilitate
mediation.


TBH, I don't think here you need any kind of mediation, it's clear the
maintainer doesn't like your proposal.
I recommend you just find a way to live with it (and I don't think
doing no-change merges in ubuntu to workaround this issue are something
too hard to do…)
To that goeal I just uploaded src:moon-buggy 1:1.0.51-1ubuntu1 to
bionic: https://launchpad.net/ubuntu/+source/moon-buggy/1:1.0.51-1ubuntu1
it should appear in MoM just fine, and it hardly brings any relevant
extra work to the MOTUs… (if you are seeking to lower the delta between
debian and ubuntu, there are bigger fishes to fry…).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Debian part of a version number when epoch is bumped

[Adam Borowski]

On Wed, Mar 28, 2018 at 04:16:19PM -0400, Jeremy Bicha wrote:
> On Mon, Feb 5, 2018 at 11:06 AM, Mattia Rizzolo  wrote:
> > Please don't consider the Debian Policy like a stick.  Or a all-kwowing
> > never-wrong oracle.
> 
> Well the maintainer refuses to make the minor change I requested. See
> the latest comments at
> https://bugs.debian.org/887740
> 
> I wish Debian had some form of informal conflict resolution besides
> the Tech Committee.

The maintainer's request here can be acted upon.

While in general I agree that a light-weight means of conflict resolution
would be nice, this issue keeps returning, thus it probably is worthy of
being mentioned in the Policy.

This is https://bugs.debian.org/881431, to which I just proposed a wording.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ When I visited the US a couple decades ago, Hillary molested and
⣾⠁⢰⠒⠀⣿⡁ groped me.  You don't believe?  Well, the burden of proof is on you!
⢿⡄⠘⠷⠚⠋⠀ Flooding a douche with obviously false accusations makes your words
⠈⠳⣄ dubious even when they happen to be true.

Re: Debian part of a version number when epoch is bumped

[Chris Lamb]

Hi Jeremy,

> I wish Debian had some form of informal conflict resolution besides
> the Tech Committee.

As DPL, I am always available to make an attempt at such resolutions.
If you wish, please contact me via lea...@debian.org.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Debian part of a version number when epoch is bumped

[Jeremy Bicha]

On Mon, Feb 5, 2018 at 11:06 AM, Mattia Rizzolo  wrote:
> Please don't consider the Debian Policy like a stick.  Or a all-kwowing
> never-wrong oracle.

Well the maintainer refuses to make the minor change I requested. See
the latest comments at
https://bugs.debian.org/887740

I wish Debian had some form of informal conflict resolution besides
the Tech Committee.

Thanks,
Jeremy Bicha

Re: Debian part of a version number when epoch is bumped

[Dimitri John Ledkov]

On 16 February 2018 at 02:00, Guillem Jover  wrote:
> Hi!
>
> Given that other parts of the original thread have started to repeat
> the same that has been discussed in previous referenced discussions,
> or even within this thread iteration, I've sat down and written a
> dpkg FAQ entry:
>
>   
> 
>
> This subthread though, prompted me to come up with something new
> though. :)
>

BTW, the othere day, Dan Watkins and I discovered twiddle-wakka
version comparison operator in ruby, also known as pessimistic version
comparison.

For example ~> 4.0.1 in ruby means >> 4.0.1 && << 5.0.0, as in, it
limits comparison within a single series. Perhaps, we also need
something like that, to limit comparisons within a given epoch only.

I guess we could adopt twiddle-wakka like syntax [1], to negate things
as you suggest.

-- 
Regards,

Dimitri.

[1] making twiddle-wakka work in dpkg, differently from ruby, should
be an explicit design goal. 

Re: Debian part of a version number when epoch is bumped

[Guillem Jover]

Hi!

Given that other parts of the original thread have started to repeat
the same that has been discussed in previous referenced discussions,
or even within this thread iteration, I've sat down and written a
dpkg FAQ entry:

  


This subthread though, prompted me to come up with something new
though. :)

On Wed, 2018-02-14 at 12:54:05 -0800, Russ Allbery wrote:
> Michael Stone  writes:
> > That doesn't matter. The fundamental problem was that it's impossible to
> > predict that a future package would have an older version of the
> > software with a newer name. Whether that's done with an epoch that
> > (horrors!) won't go away or because someone creates a crazy version
> > string that obfuscates what's being done (yay?), the unpredictable
> > breakage is the same. The solution isn't to get rid of epochs, the
> > solution is to not create packages which contain older versions of
> > software with newer names.

> Not that this is probably easily fixable at this point, but mulling on
> this a bit, I think it's because we actually have two version orderings
> that we're compressing into one ordering.

This only covers the revert case, for which epochs are really the
wrong tool. To me this looks like the equivalent of using nukes as
a town planning strategy. :)

An epoch states that the previous version-line is no longer valid
and cannot be used or relied on anymore going forward.

> We want to do two things here:
> 
> * Give a package a larger version number so that the archive knows that it
>   replaces the previous version of the package and so that clients know
>   that this package should be installed in preference to the previous
>   version.
> 
> * Express versioned dependencies in other packages, allowing you to say
>   that you need at least version 1.8 of a package and 1.6 will not
>   suffice.

For a revert the only things we really need is to make the archive
accept lower versions, and for the package managers to accept a version
downgrade as the correct "upgrade" path. In this case preserving all
the versioned dependencies/checks intact is what we'd want anyway.

> Since there are two goals, a more correct implementation would be to split
> these into two versions.  The simplest would be to have an integer
> "version epoch" field in the package metadata separate from the version
> number.  So instead of:
> 
> Version: 1.8-1
> 
> Version: 1:1.6-1
> 
> you'd have:
> 
> Version: 1.8-1
> 
> Version: 1.6-1
> Epoch: 1

I don't think splitting this into a new field would fix much, it would
just complicate things. We already had the packaging revision in
separate fields (Package_Revision, Package-Revision, Revision) long time
ago, and it got eventually folded in. :)

I think there are two ways to fix the revert problem properly:

  * Create a new archive suite with some suite-specific metadata denoting
that whatever appears in this suite has a higher pin than anything
installed, and can thus downgrade packages (following the example
of the existing NotAutomatic repo fields). You could then have:

  pkg-a_1.0-1 (sid) → pkg-a_2.0-1 (sid) → pkg-a_1.0-2 (sid-revert)

Of course one problem is that this might perhaps require for
example new apt sources entries.

  * Add a new field, which specifies this is a revert and as such a
downgrade is expected. Then the package managers would know this
is the correct "upgrade" path. For example, say:

   Version: 1.0-1

   Version: 2.0-1

   Version: 2.0-2

   Version: 1.0-2
   Reverts: 2.0-2

Perhaps, even allowing relationships in the field, dunno:

   Reverts: >= 2.0-1, <= 2.0-2

Thanks,
Guillem

Re: Debian part of a version number when epoch is bumped

[Thibaut Paumard]

Le 15/02/2018 à 14:15, Vincent Bernat a écrit :

  ❦ 15 février 2018 13:36 +0100, Thibaut Paumard  :


I meant not implemented for java, specifically. But I was wrong: we do
have e.g. java8-runtime-headless listed in
https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt

So the package mentioned by Vincent may be better off Depending on it
rather than on default-jre-headless (>= anything).


You cannot depend on a virtual package, am I wrong?


You can. The problem is when your package may be used as a 
build-dependency within the Debian infrastructure:


https://lintian.debian.org/tags/virtual-package-depends-without-real-package-depends.html

Regards, Thibaut.

Re: Debian part of a version number when epoch is bumped

[Vincent Ladeuil]

> Simon McVittie  writes:

> 3.1
> 3.11
> 95
> 98
> 2000
> 1:5.1+XP # or 2001+XP or something
> 1:5.2+Vista  # or 2006+Vista or something
> 1:7
> 1:8
> 1:8.1
> 1:10

> Ignoring the epoch would be actively harmful here: if you have a versioned
> dependency on Windows >= 8, it would be incorrect for Windows 95 to
> satisfy that dependency.

At that moment, /me was enlightened.

Re: Debian part of a version number when epoch is bumped

[Michael Stone]

On Thu, Feb 15, 2018 at 10:58:01AM +0100, Thibaut Paumard wrote:

Well, in retrospect it would have been good to declare:

Depends: default-jre-headless (>= 1:1.8), default-jre-headless (<< 2:)


Honestly, the best thing would have just been to depend on 
openjdk-8-jre-headless instead of messing around with 
default-jre-headless.


Michael Stone

Re: Debian part of a version number when epoch is bumped

[Vincent Bernat]

 ❦ 15 février 2018 13:36 +0100, Thibaut Paumard  :

> I meant not implemented for java, specifically. But I was wrong: we do
> have e.g. java8-runtime-headless listed in
> https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt
>
> So the package mentioned by Vincent may be better off Depending on it
> rather than on default-jre-headless (>= anything).

You cannot depend on a virtual package, am I wrong? I still need a
concrete alternative. That's the purpose of default-jre-headless. Note
this was an example about epoch. I don't pretend wanting to fix how to
package OOT Java packages.
-- 
Don't just echo the code with comments - make every comment count.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Debian part of a version number when epoch is bumped

[Thibaut Paumard]

Le 15/02/2018 à 13:03, gregor herrmann a écrit :

On Thu, 15 Feb 2018 10:58:01 +0100, Thibaut Paumard wrote:


The "Provides: foo-api (>= 1.8)" mentioned elsewhere in the thread sounds
also neat for java packages, but it does not seem to be implemented.


It's '(= $version') and we do have these versioned Provides since a
couple of years [0], they just haven't made their way into Policy
yet: https://bugs.debian.org/761219



Thanks.

I meant not implemented for java, specifically. But I was wrong: we do 
have e.g. java8-runtime-headless listed in

https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt

So the package mentioned by Vincent may be better off Depending on it 
rather than on default-jre-headless (>= anything).


Kind regards, Thibaut.

Re: Debian part of a version number when epoch is bumped

[Thibaut Paumard]

(Please follow-up to debian-curiosa)

Le 15/02/2018 à 11:41, Simon McVittie a écrit :


We don't have to look far to find a weird versioning scheme that can't
be represented without epochs: our largest competitor in the field of
general-purpose operating systems has such a versioning scheme. Imagine
we had a package that followed the same versioning scheme as Windows (I
could imagine a parallel universe in which Wine used the version number
of the version of Windows that it claims to emulate). If we packaged
that, using the "marketing version" wherever it's numeric or making up
something reasonable wherever it isn't, we might have had a versioning
scheme like this:


Well, as it happens, all the Windows versions also have a number that 
sorts properly, but does not always match the commercial number:





3.1
3.11
95


4.00


98


4.10


2000


NT 5.0 (which we could have translated as 5.0+NT, for instance)


1:5.1+XP # or 2001+XP or something


NT 5.1 (5.1+NT)


1:5.2+Vista  # or 2006+Vista or something


NT 6.0


1:7


Funnily, this is NT 6.1!


1:8


NT 6.2


1:8.1


NT 6.3


1:10


NT 10.0

https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions

Re: Debian part of a version number when epoch is bumped

[gregor herrmann]

On Thu, 15 Feb 2018 10:58:01 +0100, Thibaut Paumard wrote:

> The "Provides: foo-api (>= 1.8)" mentioned elsewhere in the thread sounds
> also neat for java packages, but it does not seem to be implemented.

It's '(= $version') and we do have these versioned Provides since a
couple of years [0], they just haven't made their way into Policy
yet: https://bugs.debian.org/761219


Cheers,
gregor

[0] Maybe not in all corners of the debiverse yet;
ci.debian.net/autopkgtest is, TTBOMK, the last issue:
https://bugs.debian.org/867081

One of the last fixed issues:
https://bugs.debian.org/867104

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   BOFH excuse #388:  Bad user karma. 

Re: Debian part of a version number when epoch is bumped

[Wouter Verhelst]

On Thu, Feb 15, 2018 at 10:41:23AM +, Simon McVittie wrote:
> On Thu, 15 Feb 2018 at 11:09:08 +0100, Wouter Verhelst wrote:
> > I was thinking it might be better to go to a "wildcard" epoch:
> > 
> > Depends: X (>= *:1.8)
> > 
> > would mean
> > 
> > "For this comparison, ignore the epoch, and make sure that the version
> > is at least 1.8 or above".
> 
> This would work for the "oops, that was meant to go to experimental"
> case where +really also gets used, but would do the wrong thing for the
> original purpose of epochs, which is dealing with upstream version
> numbering that doesn't match dpkg semantics.

Which would mean that in that case, the dependency should not be
declared as "X (>= *:1.8)", but instead as "X (>= 1:1.8)".

(We might at some point discover that we want to update the whole scheme
so it also supports "X (>= [1-*]:1.8)" to cover a combination of the two
cases that you and I just described, but really?)

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Debian part of a version number when epoch is bumped

[Simon McVittie]

On Thu, 15 Feb 2018 at 11:09:08 +0100, Wouter Verhelst wrote:
> I was thinking it might be better to go to a "wildcard" epoch:
> 
> Depends: X (>= *:1.8)
> 
> would mean
> 
> "For this comparison, ignore the epoch, and make sure that the version
> is at least 1.8 or above".

This would work for the "oops, that was meant to go to experimental"
case where +really also gets used, but would do the wrong thing for the
original purpose of epochs, which is dealing with upstream version
numbering that doesn't match dpkg semantics.

For instance, if your upstream uses a date-based version number (20180215
or 18.01 or something) but later decides that they don't like that
version scheme and switches to 1.0, 1.1, ..., adding an epoch is the
only way to make such versions sort correctly (if you have predicted
this situation ahead of time, you can use versions like 0~20180215, but
epochs are precisely for the situation where you weren't able to predict
how upstream's version numbering would change). Helpful upstreams don't
do this, but not all upstreams are helpful, so general-purpose packaging
systems like dpkg and rpm need an "escape hatch" to cope.

We don't have to look far to find a weird versioning scheme that can't
be represented without epochs: our largest competitor in the field of
general-purpose operating systems has such a versioning scheme. Imagine
we had a package that followed the same versioning scheme as Windows (I
could imagine a parallel universe in which Wine used the version number
of the version of Windows that it claims to emulate). If we packaged
that, using the "marketing version" wherever it's numeric or making up
something reasonable wherever it isn't, we might have had a versioning
scheme like this:

3.1
3.11
95
98
2000
1:5.1+XP # or 2001+XP or something
1:5.2+Vista  # or 2006+Vista or something
1:7
1:8
1:8.1
1:10

Ignoring the epoch would be actively harmful here: if you have a versioned
dependency on Windows >= 8, it would be incorrect for Windows 95 to
satisfy that dependency.

smcv

Re: Debian part of a version number when epoch is bumped

[Wouter Verhelst]

On Wed, Feb 14, 2018 at 04:28:41PM -0500, Michael Stone wrote:
> On Wed, Feb 14, 2018 at 12:54:05PM -0800, Russ Allbery wrote:
> > Since there are two goals, a more correct implementation would be to split
> > these into two versions.  The simplest would be to have an integer
> > "version epoch" field in the package metadata separate from the version
> > number.  So instead of:
> > 
> > Version: 1.8-1
> > 
> > Version: 1:1.6-1
> > 
> > you'd have:
> > 
> > Version: 1.8-1
> > 
> > Version: 1.6-1
> > Epoch: 1
> > 
> > We then could implement the separate semantics: only the version field
> > would be used for interpackage dependencies, so 1.6-1 with epoch 1 would
> > not satisfy >= 1.8 dependencies, but DAK and apt clients would know that
> > any package with epoch 1 supersedes packages with no epoch for archive and
> > default installation purposes.
> > 
> > Of course, getting to that from where we are now may be substantially more
> > trouble than it's worth, and it would necessarily be a very slow rollout
> > process (and there are still issues with unique filenames).
> 
> I don't think you'd need to change the package metadata for this, just
> change the comparison rules. I'm not entirely sure what the semantics should
> be, though--a simple depends >= is easy, but what about conflicts and breaks
> with <= *:1.8)

would mean

"For this comparison, ignore the epoch, and make sure that the version
is at least 1.8 or above".

Beyond that, the usual semantics of all the operators would apply. No
need for "special" operators or metadata format changes.

I was thinking for a moment that it might be useful to have that
implemented as a "general" thing, but then I cannot think of any
situation where a dependency of the form "any version of this package,
as long as it has a Debian revision of 2 or above" might be useful.
Given that, it might also be good to state that wildcard version
comparisons may not include the debian revision, only the upstream
version number.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Debian part of a version number when epoch is bumped

[Wouter Verhelst]

On Wed, Feb 14, 2018 at 04:29:20PM +0100, Michael Biebl wrote:
> Am 14.02.2018 um 16:08 schrieb Andrey Rahmatullin:
> > On Wed, Feb 14, 2018 at 01:57:16PM +0100, Vincent Bernat wrote:
> >> It's not only an infrastructure problem. If you Depends on X (>= 1.8),
> >> this will be true with X 1:1.6 as well.
> > Or with 1.8+really1.6.
> 
> But this problem will fix itself (after a release cycle at most). An
> epoch stays around forever.
> 
> From personal experience I've seen enough packages which declared a
> dependency on libfoo-dev (x.y) and forgot the epoch.

Then they get a bug filed and the problem is solved.

> epochs in library packages are extremely bad and should be avoided at
> all costs.

I can see why they might be confusing, and I can see why some people
prefer the +really approach, even though I think that's silly.

To go from there to "should be avoided at all costs" is a bit overdoing
it, though.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Debian part of a version number when epoch is bumped

[Thibaut Paumard]

Le 14/02/2018 à 18:52, Vincent Bernat a écrit :

More concrete example (now a bit in the past). On Wheezy, you want to
depend on a 1.8 JRE (you package independently). You put
default-jre-headless (>= 1.8). Since you have forgotten about the epoch,
this pulls Wheezy default-jre-headless (1:1.7-47+deb7u2). So you add the
epoch to both your own package version default-jre-headless (1:1.8-1)
and to the dependency. All good. You upgrade to Jessie and rebuild
everything. Jessie comes with default-jre-headless (2:1.7-52) which
shadows your default-jre-headless (1:1.8-1) package.



Dear Vincent,

Well, in retrospect it would have been good to declare:

Depends: default-jre-headless (>= 1:1.8), default-jre-headless (<< 2:)

when you first added the epoch to the Depends line. In general it's not 
easy to predict which future version of a package will actually break 
you package.


The "Provides: foo-api (>= 1.8)" mentioned elsewhere in the thread 
sounds also neat for java packages, but it does not seem to be implemented.


What I don't quite understand: are you distributing your own 
default-jre-headless package, with a version later than the one in 
Debian? I'm not sure overriding a "default" package with a custom one is 
a good idea. That depends on the context of course.


In fact, one could argue that you should perhaps Depend on a specific 
JRE instead (or an bunch of JREs with | in between). But I understand 
you are just showing a real-life example where bumping the epoch caused 
headaches to "someone else".



Kind regards, Thibaut.

Re: Debian part of a version number when epoch is bumped

[Adam Borowski]

On Thu, Feb 15, 2018 at 08:50:58AM +0100, gregor herrmann wrote:
> On Thu, 15 Feb 2018 08:45:23 +0100, Adam Borowski wrote:
> 
> > Package foo
> > Version: 2.0-really1.5-1
> > Provides: foo-api-1.5
> 
> Or:
> Provides: foo-api (= 1.5)

There is a difference -- some features might be added (usually backported)
to a stable branch of foo-1.5, so a depender may want foo-api-1.5 >= 1.5.42
as it has something that's missing or buggy in 1.5.41.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ The bill with 3 years prison for mentioning Polish concentration
⣾⠁⢰⠒⠀⣿⡁ camps is back.  What about KL Warschau (operating until 1956)?
⢿⡄⠘⠷⠚⠋⠀ Zgoda?  Łambinowice?  Most ex-German KLs?  If those were "soviet
⠈⠳⣄ puppets", Bereza Kartuska?  Sikorski's camps in UK (thanks Brits!)?

Re: Debian part of a version number when epoch is bumped

[gregor herrmann]

On Thu, 15 Feb 2018 08:45:23 +0100, Adam Borowski wrote:

> Package foo
> Version: 2.0-really1.5-1
> Provides: foo-api-1.5

Or:
Provides: foo-api (= 1.5)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   BOFH excuse #179:  multicasts on broken packets 

Re: Debian part of a version number when epoch is bumped

[Adam Borowski]

On Wed, Feb 14, 2018 at 02:41:37PM -0600, Matt Zagrabelny wrote:
> On Wed, Feb 14, 2018 at 2:15 PM, Michael Stone  wrote:
> > On Wed, Feb 14, 2018 at 09:05:05PM +0100, Vincent Bernat wrote:
> >
> >> In the example above, while in Wheezy, the dependency was perfectly
> >> correct. It became wrong because of the epoch bump (for no obvious
> >> reason). For software we distribute ourselves, this change can be caught
> >> at some point before the release (or by automation, like you suggest),
> >> but for people packaging stuff outside Debian, this can be far more
> >> painful.
> 
> How about introducing an Upstream-Version field? It can go up or down
> (forwards or backwards, newer or older) independent of the Debian (package)
> version.

Would require every program that parses version numbers to implement this. 
We already can do so via Provides (versioned or even non-versioned).

> ITP
> Package foo
> Version: 1.0-1
> 
> Then a new upload
> # error...
> Package foo
> Version: 2.0-1 (really 1.5)
> 
> Current corrections:
> Package foo
> Version: 1:1.5-1
> or
> Version 2.0-really1.5-1

Package foo
Version: 2.0-really1.5-1
Provides: foo-api-1.5


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ The bill with 3 years prison for mentioning Polish concentration
⣾⠁⢰⠒⠀⣿⡁ camps is back.  What about KL Warschau (operating until 1956)?
⢿⡄⠘⠷⠚⠋⠀ Zgoda?  Łambinowice?  Most ex-German KLs?  If those were "soviet
⠈⠳⣄ puppets", Bereza Kartuska?  Sikorski's camps in UK (thanks Brits!)?

Re: Debian part of a version number when epoch is bumped

[Simon McVittie]

On Wed, 14 Feb 2018 at 15:33:45 -0500, Michael Stone wrote:
> The fundamental problem was that it's impossible to
> predict that a future package would have an older version of the software
> with a newer name. Whether that's done with an epoch that (horrors!) won't
> go away or because someone creates a crazy version string that obfuscates
> what's being done (yay?), the unpredictable breakage is the same.

When using an epoch, all future versions have to use the (same or higher)
epoch, all future version references (Depends/Breaks/etc.) have to use
it, and whenever someone forgets to include it in a version reference
there is, as you said, unpredictable breakage.

When using a mangled version number (2+really1) the same unpredictable
breakage exists, but only for a finite time. glib2.0 had the popular
"oops, that was meant to have gone to experimental" mistake during
wheezy development, and has a +really version number in wheezy; but this
weirdness could be discarded next time a new upstream version was ready
to go into testing, and glib2.0 in jessie is back to being a normal
version number. dbus had the same thing during buster development, but
got a new upstream version (greater than the one I uploaded to the wrong
suite) not long after, so that mistake never even appeared in a release.
That seems a lot less bad than epochs.

(Of course, it would be better still if maintainers never made mistakes,
but we have considerable anecdotal evidence that this is an unrealistic
assumption.)

If this class of mistake is going to lead to unpredictable breakage
either way, I'd much prefer it to be temporary rather than permanent.

> The solution isn't to get rid of epochs, the solution is to not create
> packages which contain older versions of software with newer names.

As much as I'd love to have it somehow be impossible to upload to
unstable when you meant experimental, I'm not sure how to get there
from here. Maintainers do make mistakes, and the closest I can think of
to having automation to catch this mistake would be to autoreject the
Lintian tag experimental-to-unstable-without-comment, but you can see from
,
how many false positives that tag has.

Acknowledging that mistakes happen, and making sure they can be reverted,
seems a useful design principle (analogous to the GUI design principle of
offering an undo operation instead of an "are you sure?" prompt). We can
revert every other brown-paper-bag bug with a re-upload with a higher
revision number (or artificially-slightly-higher upstream version
number in the rarer case where the orig.tar.* is bad); but because
version numbers in a suite aren't allowed to go backwards, uploading
an upstream branch into a suite for which it is not yet ready can't be
reverted without escalating more-significant parts of the version number,
either via an epoch or the +really hack.

smcv

Re: Debian part of a version number when epoch is bumped

[Michael Stone]

On Wed, Feb 14, 2018 at 02:19:01PM -0800, Russ Allbery wrote:

Well, it also has the function of getting rid of the old package and
being part of the normal upgrade path.  The latter is important.  If
the previous version had major data loss or security issues,
introducing a new package with a different name doesn't have the
semantics you want.



Well, epochs don't magically do that either. :)


They certainly do?  Or I'm missing your point.  (To be clear, by "get rid
of the old package" I mean "from the active Debian archive," not from
everywhere it was ever installed.)


I meant in terms of cleaning up whatever's actually busted on user 
systems. You usually need to do something in that case beyond just 
changing the epoch.


Mike Stone

Re: Debian part of a version number when epoch is bumped

[Russ Allbery]

Michael Stone  writes:
> On Wed, Feb 14, 2018 at 01:38:53PM -0800, Russ Allbery wrote:

>>> Another way to think of it is that the epoch should really be evaluated
>>> as part of the package name rather than the version string--it's
>>> basically a mechanism to avoid renaming a package for purely aesthetic
>>> reasons.

>> Well, it also has the function of getting rid of the old package and
>> being part of the normal upgrade path.  The latter is important.  If
>> the previous version had major data loss or security issues,
>> introducing a new package with a different name doesn't have the
>> semantics you want.

> Well, epochs don't magically do that either. :)

They certainly do?  Or I'm missing your point.  (To be clear, by "get rid
of the old package" I mean "from the active Debian archive," not from
everywhere it was ever installed.)

> What I can't think of is cases where it wouldn't work to have a new
> package plus a transition/cleanup package.

Yes, true, that also works.

-- 
Russ Allbery (r...@debian.org)   

Re: Debian part of a version number when epoch is bumped

[Michael Stone]

On Wed, Feb 14, 2018 at 01:38:53PM -0800, Russ Allbery wrote:

Another way to think of it is that the epoch should really be evaluated
as part of the package name rather than the version string--it's
basically a mechanism to avoid renaming a package for purely aesthetic
reasons.


Well, it also has the function of getting rid of the old package and being
part of the normal upgrade path.  The latter is important.  If the
previous version had major data loss or security issues, introducing a new
package with a different name doesn't have the semantics you want.


Well, epochs don't magically do that either. :) What I can't think of is 
cases where it wouldn't work to have a new package plus a 
transition/cleanup package. It's somewhat more work, but that's probably 
a good thing--and it would make what's going on a lot more obvious.


Mike Stone

Re: Debian part of a version number when epoch is bumped

[Russ Allbery]

Michael Stone  writes:

> I don't think you'd need to change the package metadata for this, just
> change the comparison rules. I'm not entirely sure what the semantics
> should be, though--a simple depends >= is easy, but what about conflicts
> and breaks with < worth.

Yeah, that would work too, although you'd need to use a different
comparison function for dependencies than for determining the default
version of a package to install.  I'm not sure which is less confusing;
it's kind of confusing either way.

> Another way to think of it is that the epoch should really be evaluated
> as part of the package name rather than the version string--it's
> basically a mechanism to avoid renaming a package for purely aesthetic
> reasons.

Well, it also has the function of getting rid of the old package and being
part of the normal upgrade path.  The latter is important.  If the
previous version had major data loss or security issues, introducing a new
package with a different name doesn't have the semantics you want.

-- 
Russ Allbery (r...@debian.org)   

Re: Debian part of a version number when epoch is bumped

[Michael Stone]

On Wed, Feb 14, 2018 at 12:54:05PM -0800, Russ Allbery wrote:

Since there are two goals, a more correct implementation would be to split
these into two versions.  The simplest would be to have an integer
"version epoch" field in the package metadata separate from the version
number.  So instead of:

Version: 1.8-1

Version: 1:1.6-1

you'd have:

Version: 1.8-1

Version: 1.6-1
Epoch: 1

We then could implement the separate semantics: only the version field
would be used for interpackage dependencies, so 1.6-1 with epoch 1 would
not satisfy >= 1.8 dependencies, but DAK and apt clients would know that
any package with epoch 1 supersedes packages with no epoch for archive and
default installation purposes.

Of course, getting to that from where we are now may be substantially more
trouble than it's worth, and it would necessarily be a very slow rollout
process (and there are still issues with unique filenames).


I don't think you'd need to change the package metadata for this, just 
change the comparison rules. I'm not entirely sure what the semantics 
should be, though--a simple depends >= is easy, but what about conflicts 
and breaks with 

Re: Debian part of a version number when epoch is bumped

[Russ Allbery]

Michael Stone  writes:

> That doesn't matter. The fundamental problem was that it's impossible to
> predict that a future package would have an older version of the
> software with a newer name. Whether that's done with an epoch that
> (horrors!) won't go away or because someone creates a crazy version
> string that obfuscates what's being done (yay?), the unpredictable
> breakage is the same. The solution isn't to get rid of epochs, the
> solution is to not create packages which contain older versions of
> software with newer names.

Not that this is probably easily fixable at this point, but mulling on
this a bit, I think it's because we actually have two version orderings
that we're compressing into one ordering.

We want to do two things here:

* Give a package a larger version number so that the archive knows that it
  replaces the previous version of the package and so that clients know
  that this package should be installed in preference to the previous
  version.

* Express versioned dependencies in other packages, allowing you to say
  that you need at least version 1.8 of a package and 1.6 will not
  suffice.

These seem like the same thing, but they subtly aren't.  There are times
when we want to tell the archive to replace version 1.8 with 1.6, and tell
all apt clients to install 1.6 in preference to 1.8, but do not want that
package to satisfy a version dependency of >= 1.8.

Since there are two goals, a more correct implementation would be to split
these into two versions.  The simplest would be to have an integer
"version epoch" field in the package metadata separate from the version
number.  So instead of:

Version: 1.8-1

Version: 1:1.6-1

you'd have:

Version: 1.8-1

Version: 1.6-1
Epoch: 1

We then could implement the separate semantics: only the version field
would be used for interpackage dependencies, so 1.6-1 with epoch 1 would
not satisfy >= 1.8 dependencies, but DAK and apt clients would know that
any package with epoch 1 supersedes packages with no epoch for archive and
default installation purposes.

Of course, getting to that from where we are now may be substantially more
trouble than it's worth, and it would necessarily be a very slow rollout
process (and there are still issues with unique filenames).

-- 
Russ Allbery (r...@debian.org)   

Re: Debian part of a version number when epoch is bumped

[Michael Stone]

On Wed, Feb 14, 2018 at 02:41:37PM -0600, Matt Zagrabelny wrote:

How about introducing an Upstream-Version field? It can go up or down (forwards
or backwards, newer or older) independent of the Debian (package) version.


I don't understand what problem that solves.


The Depends in the control can then look for Upstream-Version and use that if
it is set and fail back to Version if there is no Upstream-Version.


So now the dependency rules get more complicated, and probably even more 
confusing than epochs.


Mike Stone

Re: Debian part of a version number when epoch is bumped

[Matt Zagrabelny]

On Wed, Feb 14, 2018 at 2:15 PM, Michael Stone  wrote:

> On Wed, Feb 14, 2018 at 09:05:05PM +0100, Vincent Bernat wrote:
>
>> In the example above, while in Wheezy, the dependency was perfectly
>> correct. It became wrong because of the epoch bump (for no obvious
>> reason). For software we distribute ourselves, this change can be caught
>> at some point before the release (or by automation, like you suggest),
>> but for people packaging stuff outside Debian, this can be far more
>> painful.
>>
>
> It isn't clear how getting rid of epochs would prevent crazy versioning.
> You'd have just as much trouble with 1.8-really1.7-again1.8-fooledyou1.7
>

How about introducing an Upstream-Version field? It can go up or down
(forwards or backwards, newer or older) independent of the Debian (package)
version.

ITP
Package foo
Version: 1.0-1

Then a new upload
# error...
Package foo
Version: 2.0-1 (really 1.5)

Current corrections:
Package foo
Version: 1:1.5-1
or
Version 2.0-really1.5-1

Instead use a new field to correct:
Package foo
Version: 2.0-2
Upstream-Version: 1.5-1

debian/changelog
foo (2.0-2 Upstream:1.5-1) unstable; urgency=low

The Depends in the control can then look for Upstream-Version and use that
if it is set and fail back to Version if there is no Upstream-Version.

Just an idea.

-m

Re: Debian part of a version number when epoch is bumped

[Michael Stone]

On Wed, Feb 14, 2018 at 09:24:04PM +0100, Vincent Bernat wrote:

❦ 14 février 2018 15:15 -0500, Michael Stone  :


In the example above, while in Wheezy, the dependency was perfectly
correct. It became wrong because of the epoch bump (for no obvious
reason). For software we distribute ourselves, this change can be caught
at some point before the release (or by automation, like you suggest),
but for people packaging stuff outside Debian, this can be far more
painful.


It isn't clear how getting rid of epochs would prevent crazy
versioning. You'd have just as much trouble with
1.8-really1.7-again1.8-fooledyou1.7


But they don't stay forever. They may never appear in a release.


That doesn't matter. The fundamental problem was that it's impossible to 
predict that a future package would have an older version of the 
software with a newer name. Whether that's done with an epoch that 
(horrors!) won't go away or because someone creates a crazy version 
string that obfuscates what's being done (yay?), the unpredictable 
breakage is the same. The solution isn't to get rid of epochs, the 
solution is to not create packages which contain older versions of

software with newer names.

Mike Stone

Re: Debian part of a version number when epoch is bumped

[Vincent Bernat]

 ❦ 14 février 2018 15:15 -0500, Michael Stone  :

>>In the example above, while in Wheezy, the dependency was perfectly
>>correct. It became wrong because of the epoch bump (for no obvious
>>reason). For software we distribute ourselves, this change can be caught
>>at some point before the release (or by automation, like you suggest),
>>but for people packaging stuff outside Debian, this can be far more
>>painful.
>
> It isn't clear how getting rid of epochs would prevent crazy
> versioning. You'd have just as much trouble with
> 1.8-really1.7-again1.8-fooledyou1.7

But they don't stay forever. They may never appear in a release.
-- 
Suspicion always haunts the guilty mind.
-- Wm. Shakespeare


signature.asc
Description: PGP signature

Re: Debian part of a version number when epoch is bumped

[Michael Stone]

On Wed, Feb 14, 2018 at 09:05:05PM +0100, Vincent Bernat wrote:

In the example above, while in Wheezy, the dependency was perfectly
correct. It became wrong because of the epoch bump (for no obvious
reason). For software we distribute ourselves, this change can be caught
at some point before the release (or by automation, like you suggest),
but for people packaging stuff outside Debian, this can be far more
painful.


It isn't clear how getting rid of epochs would prevent crazy versioning. 
You'd have just as much trouble with 
1.8-really1.7-again1.8-fooledyou1.7

Re: Debian part of a version number when epoch is bumped

[Vincent Bernat]

 ❦ 14 février 2018 21:11 +0200, Lars Wirzenius  :

>> > > > It's not only an infrastructure problem. If you Depends on X (>= 1.8),
>> > > > this will be true with X 1:1.6 as well.
> ...
>> That's exactly the point. You wanted X >= 1.8 and you get X 1.6.
>
> I don't think that's what you said, or at least it was hard for me to
> understand it that way.

Totally possible.

>> More concrete example (now a bit in the past). On Wheezy, you want to
>> depend on a 1.8 JRE (you package independently). You put
>> default-jre-headless (>= 1.8). Since you have forgotten about the epoch,
>> this pulls Wheezy default-jre-headless (1:1.7-47+deb7u2). So you add the
>> epoch to both your own package version default-jre-headless (1:1.8-1)
>> and to the dependency. All good. You upgrade to Jessie and rebuild
>> everything. Jessie comes with default-jre-headless (2:1.7-52) which
>> shadows your default-jre-headless (1:1.8-1) package.

> I think I now understand what you mean: you're actually worried not
> that version numbers compare in illogical ways, but that people write
> wrong versions in dependencies.

In the example above, while in Wheezy, the dependency was perfectly
correct. It became wrong because of the epoch bump (for no obvious
reason). For software we distribute ourselves, this change can be caught
at some point before the release (or by automation, like you suggest),
but for people packaging stuff outside Debian, this can be far more
painful.
-- 
Don't stop with your first draft.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Debian part of a version number when epoch is bumped

[Lars Wirzenius]

On Wed, 2018-02-14 at 18:52 +0100, Vincent Bernat wrote:
>  ❦ 14 février 2018 16:09 +0200, Lars Wirzenius  :
> 
> > > > It's not only an infrastructure problem. If you Depends on X (>= 1.8),
> > > > this will be true with X 1:1.6 as well.
...
> That's exactly the point. You wanted X >= 1.8 and you get X 1.6.

I don't think that's what you said, or at least it was hard for me to
understand it that way.

> More concrete example (now a bit in the past). On Wheezy, you want to
> depend on a 1.8 JRE (you package independently). You put
> default-jre-headless (>= 1.8). Since you have forgotten about the epoch,
> this pulls Wheezy default-jre-headless (1:1.7-47+deb7u2). So you add the
> epoch to both your own package version default-jre-headless (1:1.8-1)
> and to the dependency. All good. You upgrade to Jessie and rebuild
> everything. Jessie comes with default-jre-headless (2:1.7-52) which
> shadows your default-jre-headless (1:1.8-1) package.

I think I now understand what you mean: you're actually worried not
that version numbers compare in illogical ways, but that people write
wrong versions in dependencies.

I don't think that has anything to do with epochs, and I don't think
getting rid of epochs would actually solve that problem. The root
cause for people getting version numbers wrong in dependencies, in my
expeience as a Debian developer, is that not all version numbers are
very simple, and that updating them is a manual task.

It's true that epochs make version numbers a little more complicated,
but not as much as sheer length. The median length of version numbers
in stretch is 8 characters, looking only at version numbers without an
epoch. Getting those wrong is very easy, even without epochs, and not
really harder than with epochs, in my experience. I admit an epoch may
trip someone, but it's not happening often enough that it's a problem
worth solving by getting rid of epochs, in my opinion.

I know of only two ways to get version numbers correct: automation and
testing. For shared libraries, we have automation. Maybe we can have
that for other classes of dependencies as well. For everything else,
we're going to need testing.

Automating all generation and updating of runtime and build time
depencies would be a good thing to have. Not an easy thing to achieve,
of course.

I, for one, would welcome a general AI for automating this. Skynet is
a worth it if we can get versioned dependencies right every time.

signature.asc
Description: This is a digitally signed message part

Re: Debian part of a version number when epoch is bumped

[Vincent Bernat]

 ❦ 14 février 2018 16:09 +0200, Lars Wirzenius  :

>> > It's not only an infrastructure problem. If you Depends on X (>= 1.8),
>> > this will be true with X 1:1.6 as well.
>> 
>> Only if your program is severely buggy.
>> 
>> Hint: either it matches dpkg --compare-versions exactly, or it is a
>> severe bug.
>
> For extra clarity:
>
> $ if dpkg --compare-versions 1.8 '>=' 1:1.6; then echo 1.8 comes after
> 1:1.6; else echo no it does not; fi
> no it does not
> $ 
>
> A version with a lower epoch (or no epoch, which is implicitly a zero
> epoch) always compares less than one with a higher epoch. This is
> regardless of what comes after the epoch in a version number.
> Otherwise there would be little point to epochs.

That's exactly the point. You wanted X >= 1.8 and you get X 1.6.

More concrete example (now a bit in the past). On Wheezy, you want to
depend on a 1.8 JRE (you package independently). You put
default-jre-headless (>= 1.8). Since you have forgotten about the epoch,
this pulls Wheezy default-jre-headless (1:1.7-47+deb7u2). So you add the
epoch to both your own package version default-jre-headless (1:1.8-1)
and to the dependency. All good. You upgrade to Jessie and rebuild
everything. Jessie comes with default-jre-headless (2:1.7-52) which
shadows your default-jre-headless (1:1.8-1) package.
-- 
A horse!  A horse!  My kingdom for a horse!
-- Wm. Shakespeare, "Richard III"


signature.asc
Description: PGP signature

Re: Debian part of a version number when epoch is bumped

[Marc Haber]

On Wed, 14 Feb 2018 16:29:20 +0100, Michael Biebl 
wrote:
>Am 14.02.2018 um 16:08 schrieb Andrey Rahmatullin:
>> On Wed, Feb 14, 2018 at 01:57:16PM +0100, Vincent Bernat wrote:
>>> It's not only an infrastructure problem. If you Depends on X (>= 1.8),
>>> this will be true with X 1:1.6 as well.
>> Or with 1.8+really1.6.
>
>But this problem will fix itself (after a release cycle at most). An
>epoch stays around forever.

Ack. A +really version number is a totally acceptable workaround in my
opinion.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Debian part of a version number when epoch is bumped

[Andrey Rahmatullin]

On Wed, Feb 14, 2018 at 04:29:20PM +0100, Michael Biebl wrote:
> >> It's not only an infrastructure problem. If you Depends on X (>= 1.8),
> >> this will be true with X 1:1.6 as well.
> > Or with 1.8+really1.6.
> 
> But this problem will fix itself (after a release cycle at most).
Hmm, why after a release cycle at most?




-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Debian part of a version number when epoch is bumped

[Michael Biebl]

Am 14.02.2018 um 14:31 schrieb Jeremy Bicha:
> On Wed, Feb 14, 2018 at 7:57 AM, Vincent Bernat  wrote:
>>  ❦ 14 février 2018 12:53 +0100, Wouter Verhelst  :
>>
> Would it hurt to take those epoch bumps into Debian?

 Depends on what you mean by hurt. I see epochs being used w/o much
 tought or care, on many situations where they are not supposed to be
 used, and they are permanent stigmas.
>>>
>>> I wonder where this representation of "epoch" as a "stigma" comes from.
>>> They're a part of a version number. They're as much a stigma as the "57"
>>> in "libavcodec57". What's the big deal? Just use it if you need to, and
>>> be done with it.
>>>
>>> There's really really really nothing wrong with using an epoch. If some
>>> of our (or someone else's) infrastructure has issues dealing with them,
>>> then that's a bug in the infrastructure and we should fix it. But nobody
>>> should be afraid of using an epoch when the upstream version number
>>> changes incompatibly, because *that's what they're for*.
>>
>> It's not only an infrastructure problem. If you Depends on X (>= 1.8),
>> this will be true with X 1:1.6 as well.
> 
> In the particular case of gnome-calculator, virtually nothing depends
> on a particular version of gnome-calculator. And in this case, it's
> probably better for me to just go ahead and upload the epoch bump,
> upsetting a few people, but it's not really a big deal at all and
> saves a bunch of needless work in the long run.

I understand where you are coming from as Ubuntu maintainer, but I also
share the opinion that packaging bugs should not be pushed upstream. If
we allowed that for every downstream we'd have a big mess.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Debian part of a version number when epoch is bumped

[Michael Biebl]

Am 14.02.2018 um 16:08 schrieb Andrey Rahmatullin:
> On Wed, Feb 14, 2018 at 01:57:16PM +0100, Vincent Bernat wrote:
>> It's not only an infrastructure problem. If you Depends on X (>= 1.8),
>> this will be true with X 1:1.6 as well.
> Or with 1.8+really1.6.

But this problem will fix itself (after a release cycle at most). An
epoch stays around forever.

From personal experience I've seen enough packages which declared a
dependency on libfoo-dev (x.y) and forgot the epoch.
epochs in library packages are extremely bad and should be avoided at
all costs.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Debian part of a version number when epoch is bumped

[Andrey Rahmatullin]

On Wed, Feb 14, 2018 at 01:57:16PM +0100, Vincent Bernat wrote:
> It's not only an infrastructure problem. If you Depends on X (>= 1.8),
> this will be true with X 1:1.6 as well.
Or with 1.8+really1.6.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Debian part of a version number when epoch is bumped

[Raphael Hertzog]

On Wed, 14 Feb 2018, Wouter Verhelst wrote:
> Well, obviously, because 1:1.6 is larger than 1.8, according to our
> versioning rules.
> 
> I agree that the epoch not being in the file name makes that unexpected,
> but that's a bug in whatever decides that filename, not in the use of
> the epoch.

The point is that the introduction of the epoch breaks dependencies of
existing packages. This is fine when upstream has anyway changed its
versioning scheme. But it's not so great when we just downgraded
temporarily in Debian for whatever reason.

So we want to avoid usage of epochs when it's not required by upstream's
change of versioning scheme.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Debian part of a version number when epoch is bumped

[Ian Campbell]

On Wed, 2018-02-14 at 12:53 +0100, Wouter Verhelst wrote:
> But nobody
> should be afraid of using an epoch when the upstream version number
> changes incompatibly, because *that's what they're for*.

Much of the discussion in this thread (and the recommendations not to
use them) seem to be for cases where something other than upstream
versioning discontiunity has occured though, aren't they?

Ian

Re: Debian part of a version number when epoch is bumped

[Wouter Verhelst]

On Wed, Feb 14, 2018 at 01:57:16PM +0100, Vincent Bernat wrote:
>  ❦ 14 février 2018 12:53 +0100, Wouter Verhelst  :
> 
> >> > Would it hurt to take those epoch bumps into Debian?
> >> 
> >> Depends on what you mean by hurt. I see epochs being used w/o much
> >> tought or care, on many situations where they are not supposed to be
> >> used, and they are permanent stigmas.
> >
> > I wonder where this representation of "epoch" as a "stigma" comes from.
> > They're a part of a version number. They're as much a stigma as the "57"
> > in "libavcodec57". What's the big deal? Just use it if you need to, and
> > be done with it.
> >
> > There's really really really nothing wrong with using an epoch. If some
> > of our (or someone else's) infrastructure has issues dealing with them,
> > then that's a bug in the infrastructure and we should fix it. But nobody
> > should be afraid of using an epoch when the upstream version number
> > changes incompatibly, because *that's what they're for*.
> 
> It's not only an infrastructure problem. If you Depends on X (>= 1.8),
> this will be true with X 1:1.6 as well.

Well, obviously, because 1:1.6 is larger than 1.8, according to our
versioning rules.

I agree that the epoch not being in the file name makes that unexpected,
but that's a bug in whatever decides that filename, not in the use of
the epoch.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Debian part of a version number when epoch is bumped

[Lars Wirzenius]

On Wed, 2018-02-14 at 11:54 -0200, Henrique de Moraes Holschuh wrote:
> On Wed, 14 Feb 2018, Vincent Bernat wrote:
> > It's not only an infrastructure problem. If you Depends on X (>= 1.8),
> > this will be true with X 1:1.6 as well.
> 
> Only if your program is severely buggy.
> 
> Hint: either it matches dpkg --compare-versions exactly, or it is a
> severe bug.

For extra clarity:

$ if dpkg --compare-versions 1.8 '>=' 1:1.6; then echo 1.8 comes after
1:1.6; else echo no it does not; fi
no it does not
$ 

A version with a lower epoch (or no epoch, which is implicitly a zero
epoch) always compares less than one with a higher epoch. This is
regardless of what comes after the epoch in a version number.
Otherwise there would be little point to epochs.

For the gory details, see the policy manual:
https://www.debian.org/doc/debian-policy/#s-f-version


signature.asc
Description: This is a digitally signed message part

Re: Debian part of a version number when epoch is bumped

[Steve McIntyre]

Wouter Verhelst wrote:
>On Mon, Feb 12, 2018 at 03:23:14AM +0100, Guillem Jover wrote:
>
>I wonder where this representation of "epoch" as a "stigma" comes from.
>They're a part of a version number. They're as much a stigma as the "57"
>in "libavcodec57". What's the big deal? Just use it if you need to, and
>be done with it.
>
>There's really really really nothing wrong with using an epoch. If some
>of our (or someone else's) infrastructure has issues dealing with them,
>then that's a bug in the infrastructure and we should fix it. But nobody
>should be afraid of using an epoch when the upstream version number
>changes incompatibly, because *that's what they're for*.

That's exactly my thought, yes. It's just a version number...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Every time you use Tcl, God kills a kitten." -- Malcolm Ray

Re: Debian part of a version number when epoch is bumped

[Henrique de Moraes Holschuh]

On Wed, 14 Feb 2018, Vincent Bernat wrote:
>  ❦ 14 février 2018 12:53 +0100, Wouter Verhelst  :
> >> > Would it hurt to take those epoch bumps into Debian?
> >> 
> >> Depends on what you mean by hurt. I see epochs being used w/o much
> >> tought or care, on many situations where they are not supposed to be
> >> used, and they are permanent stigmas.
> >
> > I wonder where this representation of "epoch" as a "stigma" comes from.
> > They're a part of a version number. They're as much a stigma as the "57"
> > in "libavcodec57". What's the big deal? Just use it if you need to, and
> > be done with it.
> >
> > There's really really really nothing wrong with using an epoch. If some
> > of our (or someone else's) infrastructure has issues dealing with them,
> > then that's a bug in the infrastructure and we should fix it. But nobody
> > should be afraid of using an epoch when the upstream version number
> > changes incompatibly, because *that's what they're for*.
> 
> It's not only an infrastructure problem. If you Depends on X (>= 1.8),
> this will be true with X 1:1.6 as well.

Only if your program is severely buggy.

Hint: either it matches dpkg --compare-versions exactly, or it is a
severe bug.

-- 
  Henrique Holschuh

Re: Debian part of a version number when epoch is bumped

[Jeremy Bicha]

On Wed, Feb 14, 2018 at 7:57 AM, Vincent Bernat  wrote:
>  ❦ 14 février 2018 12:53 +0100, Wouter Verhelst  :
>
>>> > Would it hurt to take those epoch bumps into Debian?
>>>
>>> Depends on what you mean by hurt. I see epochs being used w/o much
>>> tought or care, on many situations where they are not supposed to be
>>> used, and they are permanent stigmas.
>>
>> I wonder where this representation of "epoch" as a "stigma" comes from.
>> They're a part of a version number. They're as much a stigma as the "57"
>> in "libavcodec57". What's the big deal? Just use it if you need to, and
>> be done with it.
>>
>> There's really really really nothing wrong with using an epoch. If some
>> of our (or someone else's) infrastructure has issues dealing with them,
>> then that's a bug in the infrastructure and we should fix it. But nobody
>> should be afraid of using an epoch when the upstream version number
>> changes incompatibly, because *that's what they're for*.
>
> It's not only an infrastructure problem. If you Depends on X (>= 1.8),
> this will be true with X 1:1.6 as well.

In the particular case of gnome-calculator, virtually nothing depends
on a particular version of gnome-calculator. And in this case, it's
probably better for me to just go ahead and upload the epoch bump,
upsetting a few people, but it's not really a big deal at all and
saves a bunch of needless work in the long run.

Thanks,
Jeremy Bicha

Re: Debian part of a version number when epoch is bumped

[Vincent Bernat]

 ❦ 14 février 2018 12:53 +0100, Wouter Verhelst  :

>> > Would it hurt to take those epoch bumps into Debian?
>> 
>> Depends on what you mean by hurt. I see epochs being used w/o much
>> tought or care, on many situations where they are not supposed to be
>> used, and they are permanent stigmas.
>
> I wonder where this representation of "epoch" as a "stigma" comes from.
> They're a part of a version number. They're as much a stigma as the "57"
> in "libavcodec57". What's the big deal? Just use it if you need to, and
> be done with it.
>
> There's really really really nothing wrong with using an epoch. If some
> of our (or someone else's) infrastructure has issues dealing with them,
> then that's a bug in the infrastructure and we should fix it. But nobody
> should be afraid of using an epoch when the upstream version number
> changes incompatibly, because *that's what they're for*.

It's not only an infrastructure problem. If you Depends on X (>= 1.8),
this will be true with X 1:1.6 as well.
-- 
Use the fundamental control flow constructs.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Debian part of a version number when epoch is bumped

[Wouter Verhelst]

On Mon, Feb 12, 2018 at 03:23:14AM +0100, Guillem Jover wrote:
> On Fri, 2018-02-09 at 14:35:15 -0500, Jeremy Bicha wrote:
> > On Fri, Feb 9, 2018 at 2:22 PM, Andrey Rahmatullin  wrote:
> > > On Fri, Feb 09, 2018 at 06:58:49PM +0100, Philipp Kern wrote:
> > >> If Ubuntu uses an epoch without Debian following that decision, they can
> > >> never sync with Debian again, increasing the maintenance burden
> > >> indefinitely.
> 
> > > See e.g. libpulse0 (pulseaudio), sadly (I needed to repack a $job package
> > > and fix the Depends line to use the package on Debian because of that).
> > 
> > Would it hurt to take those epoch bumps into Debian?
> 
> Depends on what you mean by hurt. I see epochs being used w/o much
> tought or care, on many situations where they are not supposed to be
> used, and they are permanent stigmas.

I wonder where this representation of "epoch" as a "stigma" comes from.
They're a part of a version number. They're as much a stigma as the "57"
in "libavcodec57". What's the big deal? Just use it if you need to, and
be done with it.

There's really really really nothing wrong with using an epoch. If some
of our (or someone else's) infrastructure has issues dealing with them,
then that's a bug in the infrastructure and we should fix it. But nobody
should be afraid of using an epoch when the upstream version number
changes incompatibly, because *that's what they're for*.

Jeez.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Debian part of a version number when epoch is bumped

[Jonathan Dowland]

On Tue, Feb 06, 2018 at 03:34:50PM +0200, Lars Wirzenius wrote:

On Tue, 2018-02-06 at 13:31 +, Jonathan Dowland wrote:

On Mon, Feb 05, 2018 at 05:06:00PM +0100, Mattia Rizzolo wrote:
> This is one of the many situations where I'd like developers to *ask*
> when unsure or uncertain of something.
> So, in fact, the epoch bump was totally useless, and as it often happens
> in those cases, it's causing headaches for somebody.

Maybe introducing epochs should force a round-trip through NEW...


That would completely ruin my plan to only ever release version 1.0 of
all of my future projects, but increase the epoch instead.


Good :>



--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Debian part of a version number when epoch is bumped

[Guillem Jover]

On Fri, 2018-02-09 at 14:35:15 -0500, Jeremy Bicha wrote:
> On Fri, Feb 9, 2018 at 2:22 PM, Andrey Rahmatullin  wrote:
> > On Fri, Feb 09, 2018 at 06:58:49PM +0100, Philipp Kern wrote:
> >> If Ubuntu uses an epoch without Debian following that decision, they can
> >> never sync with Debian again, increasing the maintenance burden
> >> indefinitely.

> > See e.g. libpulse0 (pulseaudio), sadly (I needed to repack a $job package
> > and fix the Depends line to use the package on Debian because of that).
> 
> Would it hurt to take those epoch bumps into Debian?

Depends on what you mean by hurt. I see epochs being used w/o much
tought or care, on many situations where they are not supposed to be
used, and they are permanent stigmas. In addition to
, they
also reset the monotonic versioning increment, marking version
barriers at which points making comparisons becomes useless.

IMO pushing epoch bumps upstream, or doing epoch bump races to compete
with external or third-party repositories (like what happened with the
debian-multimedia packages) would be a mistake, because as I mentioned
on that referenced mail, we'd be dependent on epoch blunders from all
our downstreams, and might end up with such a mess of our version
space to make it unusable.

> The background is that gcalctool 6.4 was renamed upstream to
> gnome-calculator 3.7. An overhauled upstream version numbering system
> seemed a pretty clear case for adding an epoch. A month after this
> landed in Ubuntu, the Debian packaging used a dh_gencontrol hack to
> only use an epoch for the transitional package gcalctool allowing the
> rest of gnome-calculator to avoid an epoch. Pretty cool trick except
> that it just causes extra work in Ubuntu multiple times a year.

This is not a hack, this is how it's supposed to be done. dpkg has
supported different source and binary versions for a very long time,
if not forever.

Thanks,
Guillem

Re: Debian part of a version number when epoch is bumped

[Guillem Jover]

On Fri, 2018-02-09 at 12:01:46 +, Ian Jackson wrote:
> Seth Arnold writes ("Re: Debian part of a version number when epoch is 
> bumped"):
> > tar will treat a filename with : in it as a command to connect to a remote
> > machine via rsh and execute /etc/rmt remotely:
> > ftp://ftp.gnu.org/old-gnu/Manuals/tar/html_node/tar_127.html
> > 
> > The git repo shows that GNU tar had --force-local in 1994 (f_force_local):
> > 
> > http://git.savannah.gnu.org/cgit/tar.git/commit/?id=d3fdd8259b1dd0e5ec05d1540b10d2deba7cc864
> > 
> > Perhaps not using colons in filenames directly comes from not wanting to
> > require --force-local on every single tar invocation for decades to come?

Right, covered too in:

  <https://bugs.debian.org/792853#13>

> rsync and scp have similar behaviour.
> 
> Basically, `:' is annoying in filenames.  Encoding it would have been
> possible but we don't encode anything else.  And I think a rule
> against reusing the same upstream version with a different epoch is
> entirely sensible, anyway.

Yeah. If we decided we wanted epochs present somehow in filenames
(#551323, for which I think I've got most code in some dpkg branch,
but I'd expect there are going to be tons of things assuming filename
patterns in external tools), we'd still need to decide first how and
if to encode it, and second when to encode it. As you say, we can
consider to add the epoch to the upstream tarball or not; because in
the end that's a Debian specific construction in the same way as our
revisions.

If upstream is releasing different content using the same version, then,
well, this so broken I'm not sure it's worth supported anyway. :)
The problem could have also been introduced by Debian, by using an
inexistent version that then upstream starts reusing, which IMO then
deserves a Debian-specific versioning scheme, such as +ds or similar.
The former can also be worked around this way. So I think it does make
sense to ignore epochs for orig tarballs.

This means we still could consider introducing epochs for the rest of
the filenames, .dsc, .changes, .deb, .diff.*, etc. The problem of course
is still *.debian.tar.*.


In any case, I agree with Colin that the problem here is with DAK
forgetfulness, because all filenames ever seen by DAK should be unique
and never contain different content regardless of the time frame.


On Fri, 2018-02-09 at 18:10:54 +0100, Philipp Kern wrote:
> On 09.02.2018 17:02, Ian Jackson wrote:
> > Philipp Kern writes ("Re: Debian part of a version number when epoch is 
> > bumped"):
> >> You say upstream version. But I'd say that rollbacks are exactly that: 
> >> reuse of a different epoch with the same upstream version. Like what 
> >> happened to imagemagick multiple times.
> > 
> > I don't know precisely what you mean by "rollback".  If you mean
> > "change our mind about uploading foo new upstream version 3, and go
> > back to foo upstream version 2", I would not encourage use of an epoch
> > for that.  I would upload foo version "3+really2".  This is ugly but
> > fits much better into everything.
> 
> But how is that better than using an epoch? I fully understand why
> Ubuntu has to use this scheme because they can't use epochs. But we can.
> Why isn't this a legitimate case to use one?

We've already had this exact conversation before:

  <https://lists.debian.org/debian-devel/2013/04/msg00203.html>

Thanks,
Guillem

Re: Debian part of a version number when epoch is bumped

[Chris Lamb]

Hi Ian,

> > Yes. Please file bugs for this. :)
> > 
> > Note however that such a lintian check should not consider changelog
> > entries indicating another source package name.
> 
> Done: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889991

Done: 
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=1cadac3c48bf361c2894d56f2ef6fdf28bc32e9e


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Debian part of a version number when epoch is bumped

[Ian Campbell]

On Thu, 2018-02-08 at 11:50 +0100, Raphael Hertzog wrote:
> On Thu, 08 Feb 2018, Ian Campbell wrote:
> > Is it also the case that today we implicitly require that all
> versions
> > used in a source package name's history are unique even once the
> epochs
> > are stripped off (e.g. a given $upstream-$debianrev must be unique
> and
> > not differ only in the epoch)? If so then should policy say that
> > explicitly and/or should lintian check/warn if it isn't?
> 
> Yes. Please file bugs for this. :)
> 
> Note however that such a lintian check should not consider changelog
> entries indicating another source package name.

Done: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889991

Thanks,
Ian.

Re: Debian part of a version number when epoch is bumped

[Jeremy Bicha]

On Fri, Feb 9, 2018 at 2:22 PM, Andrey Rahmatullin  wrote:
> On Fri, Feb 09, 2018 at 06:58:49PM +0100, Philipp Kern wrote:
>> If Ubuntu uses an epoch without Debian following that decision, they can
>> never sync with Debian again, increasing the maintenance burden
>> indefinitely.
> See e.g. libpulse0 (pulseaudio), sadly (I needed to repack a $job package
> and fix the Depends line to use the package on Debian because of that).

Would it hurt to take those epoch bumps into Debian?

For instance, the only difference gnome-calculator has in Ubuntu now
is the epoch bump.

The background is that gcalctool 6.4 was renamed upstream to
gnome-calculator 3.7. An overhauled upstream version numbering system
seemed a pretty clear case for adding an epoch. A month after this
landed in Ubuntu, the Debian packaging used a dh_gencontrol hack to
only use an epoch for the transitional package gcalctool allowing the
rest of gnome-calculator to avoid an epoch. Pretty cool trick except
that it just causes extra work in Ubuntu multiple times a year.

Thanks,
Jeremy Bicha

Re: Debian part of a version number when epoch is bumped

[Andrey Rahmatullin]

On Fri, Feb 09, 2018 at 06:58:49PM +0100, Philipp Kern wrote:
> If Ubuntu uses an epoch without Debian following that decision, they can
> never sync with Debian again, increasing the maintenance burden
> indefinitely. 
See e.g. libpulse0 (pulseaudio), sadly (I needed to repack a $job package
and fix the Depends line to use the package on Debian because of that).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Debian part of a version number when epoch is bumped

[Ian Jackson]

Philipp Kern writes ("Re: Debian part of a version number when epoch is 
bumped"):
> On 09.02.2018 17:02, Ian Jackson wrote:
> > I don't know precisely what you mean by "rollback".  If you mean
> > "change our mind about uploading foo new upstream version 3, and go
> > back to foo upstream version 2", I would not encourage use of an epoch
> > for that.  I would upload foo version "3+really2".  This is ugly but
> > fits much better into everything.
> 
> But how is that better than using an epoch? I fully understand why
> Ubuntu has to use this scheme because they can't use epochs. But we can.
> Why isn't this a legitimate case to use one?

Quite apart from the filename issue, using +really means you get to
leave the mistake behind.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Debian part of a version number when epoch is bumped

[Russ Allbery]

Philipp Kern  writes:
> On 09.02.2018 18:20, Russ Allbery wrote:
>> Philipp Kern  writes:

>>> But how is that better than using an epoch? I fully understand why
>>> Ubuntu has to use this scheme because they can't use epochs. But we
>>> can.  Why isn't this a legitimate case to use one?

>> Ubuntu can use epochs.  Neither Debian nor Ubuntu can have two deb
>> files that generate the same filename (which doesn't include the
>> epoch).

> If Ubuntu uses an epoch without Debian following that decision, they can
> never sync with Debian again, increasing the maintenance burden
> indefinitely. That's the origin of the various +really versions there.

Oh, apologies, I misunderstood.  Yes, indeed, Ubuntu can't use an epoch
independent of Debian for a package also in Debian.

-- 
Russ Allbery (r...@debian.org)   

Re: Debian part of a version number when epoch is bumped

[Philipp Kern]

On 09.02.2018 18:20, Russ Allbery wrote:
> Philipp Kern  writes:
>> On 09.02.2018 17:02, Ian Jackson wrote:
> 
>>> I don't know precisely what you mean by "rollback".  If you mean
>>> "change our mind about uploading foo new upstream version 3, and go
>>> back to foo upstream version 2", I would not encourage use of an epoch
>>> for that.  I would upload foo version "3+really2".  This is ugly but
>>> fits much better into everything.
> 
>> But how is that better than using an epoch? I fully understand why
>> Ubuntu has to use this scheme because they can't use epochs. But we can.
>> Why isn't this a legitimate case to use one?
> 
> Ubuntu can use epochs.  Neither Debian nor Ubuntu can have two deb files
> that generate the same filename (which doesn't include the epoch).

If Ubuntu uses an epoch without Debian following that decision, they can
never sync with Debian again, increasing the maintenance burden
indefinitely. That's the origin of the various +really versions there.

Kind regards
Philipp Kern

Re: Debian part of a version number when epoch is bumped

[Russ Allbery]

Philipp Kern  writes:
> On 09.02.2018 17:02, Ian Jackson wrote:

>> I don't know precisely what you mean by "rollback".  If you mean
>> "change our mind about uploading foo new upstream version 3, and go
>> back to foo upstream version 2", I would not encourage use of an epoch
>> for that.  I would upload foo version "3+really2".  This is ugly but
>> fits much better into everything.

> But how is that better than using an epoch? I fully understand why
> Ubuntu has to use this scheme because they can't use epochs. But we can.
> Why isn't this a legitimate case to use one?

Ubuntu can use epochs.  Neither Debian nor Ubuntu can have two deb files
that generate the same filename (which doesn't include the epoch).

There isn't really a difference here except that Ubuntu breaks more
obviously and earlier, whereas such packages seem like they work in Debian
but then break other tools outside of DAK that expect filenames to be
unique.

-- 
Russ Allbery (r...@debian.org)   

Re: Debian part of a version number when epoch is bumped

[Colin Watson]

On Fri, Feb 09, 2018 at 04:02:42PM +, Ian Jackson wrote:
> Philipp Kern writes ("Re: Debian part of a version number when epoch is 
> bumped"):
> > You say upstream version. But I'd say that rollbacks are exactly that: 
> > reuse of a different epoch with the same upstream version. Like what 
> > happened to imagemagick multiple times.
> 
> I don't know precisely what you mean by "rollback".  If you mean
> "change our mind about uploading foo new upstream version 3, and go
> back to foo upstream version 2", I would not encourage use of an epoch
> for that.  I would upload foo version "3+really2".  This is ugly but
> fits much better into everything.

That said, even if you did use an epoch in this situation, it shouldn't
cause a problem that you're reusing the *upstream* part of the version,
because the contents of that tarball will (one hopes) be identical.
You'd just need to make sure that the Debian revision isn't reused.

-- 
Colin Watson   [cjwat...@debian.org]

Re: Debian part of a version number when epoch is bumped

[Philipp Kern]

On 09.02.2018 17:02, Ian Jackson wrote:
> Philipp Kern writes ("Re: Debian part of a version number when epoch is 
> bumped"):
>> You say upstream version. But I'd say that rollbacks are exactly that: 
>> reuse of a different epoch with the same upstream version. Like what 
>> happened to imagemagick multiple times.
> 
> I don't know precisely what you mean by "rollback".  If you mean
> "change our mind about uploading foo new upstream version 3, and go
> back to foo upstream version 2", I would not encourage use of an epoch
> for that.  I would upload foo version "3+really2".  This is ugly but
> fits much better into everything.

But how is that better than using an epoch? I fully understand why
Ubuntu has to use this scheme because they can't use epochs. But we can.
Why isn't this a legitimate case to use one?

Kind regards
Philipp Kern

Re: Debian part of a version number when epoch is bumped

[Ian Jackson]

Philipp Kern writes ("Re: Debian part of a version number when epoch is 
bumped"):
> You say upstream version. But I'd say that rollbacks are exactly that: 
> reuse of a different epoch with the same upstream version. Like what 
> happened to imagemagick multiple times.

I don't know precisely what you mean by "rollback".  If you mean
"change our mind about uploading foo new upstream version 3, and go
back to foo upstream version 2", I would not encourage use of an epoch
for that.  I would upload foo version "3+really2".  This is ugly but
fits much better into everything.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Debian part of a version number when epoch is bumped

[Philipp Kern]

On 2018-02-09 13:01, Ian Jackson wrote:

Basically, `:' is annoying in filenames.  Encoding it would have been
possible but we don't encode anything else.  And I think a rule
against reusing the same upstream version with a different epoch is
entirely sensible, anyway.


You say upstream version. But I'd say that rollbacks are exactly that: 
reuse of a different epoch with the same upstream version. Like what 
happened to imagemagick multiple times.


Kind regards
Philipp Kern

Re: Debian part of a version number when epoch is bumped

[Ian Jackson]

Seth Arnold writes ("Re: Debian part of a version number when epoch is bumped"):
> tar will treat a filename with : in it as a command to connect to a remote
> machine via rsh and execute /etc/rmt remotely:
> ftp://ftp.gnu.org/old-gnu/Manuals/tar/html_node/tar_127.html
> 
> The git repo shows that GNU tar had --force-local in 1994 (f_force_local):
> 
> http://git.savannah.gnu.org/cgit/tar.git/commit/?id=d3fdd8259b1dd0e5ec05d1540b10d2deba7cc864
> 
> Perhaps not using colons in filenames directly comes from not wanting to
> require --force-local on every single tar invocation for decades to come?

rsync and scp have similar behaviour.

Basically, `:' is annoying in filenames.  Encoding it would have been
possible but we don't encode anything else.  And I think a rule
against reusing the same upstream version with a different epoch is
entirely sensible, anyway.

There are a lot of things I did many years ago which now turn out to
have been mistakes; I don't think this is one of them.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Debian part of a version number when epoch is bumped

[Raphael Hertzog]

On Thu, 08 Feb 2018, Ian Campbell wrote:
> Is it also the case that today we implicitly require that all versions
> used in a source package name's history are unique even once the epochs
> are stripped off (e.g. a given $upstream-$debianrev must be unique and
> not differ only in the epoch)? If so then should policy say that
> explicitly and/or should lintian check/warn if it isn't?

Yes. Please file bugs for this. :)

Note however that such a lintian check should not consider changelog
entries indicating another source package name.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Debian part of a version number when epoch is bumped

[Ian Campbell]

On Wed, 2018-02-07 at 13:51 +, Ian Jackson wrote:
> I suggest something like this wording to replace the following
> paragraphs about the epoch:
> 
>Epochs exist to cope with changes to the upstream version numbering
>scheme, and some other difficult cases.  The epoch is a powerful
>tool, but increasing the epoch it has downsides and should be
>avoided when possible.
> 
>If you think you need to increase the epoch for a package, please
>consult debian-devel first.

Is it also the case that today we implicitly require that all versions
used in a source package name's history are unique even once the epochs
are stripped off (e.g. a given $upstream-$debianrev must be unique and
not differ only in the epoch)? If so then should policy say that
explicitly and/or should lintian check/warn if it isn't?

Ian.

Re: Debian part of a version number when epoch is bumped

[Seth Arnold]

On Tue, Feb 06, 2018 at 10:19:25PM +, Colin Watson wrote:
> > Do you happen to know what was the reason somebody way back in time
> > decided to not consider the epoch in the filenames?
> 
> My understanding is that it would have caused some kind of problems for
> common operations at the time involving things like tar, but I'm afraid
> I forget the details.  Ian Jackson would probably know ...

tar will treat a filename with : in it as a command to connect to a remote
machine via rsh and execute /etc/rmt remotely:
ftp://ftp.gnu.org/old-gnu/Manuals/tar/html_node/tar_127.html

The git repo shows that GNU tar had --force-local in 1994 (f_force_local):

http://git.savannah.gnu.org/cgit/tar.git/commit/?id=d3fdd8259b1dd0e5ec05d1540b10d2deba7cc864

Perhaps not using colons in filenames directly comes from not wanting to
require --force-local on every single tar invocation for decades to come?

Thanks


signature.asc
Description: PGP signature

Re: Debian part of a version number when epoch is bumped

[Wouter Verhelst]

On Wed, Feb 07, 2018 at 09:18:03AM +, Jonathan McDowell wrote:
> You can't put a : in a filename on a FAT filesystem.

Interestingly enough, you *can* put a : in a filename on an NTFS
filesystem, if you do it with ntfs-3g. Windows won't like it, though.
Yes, I found that out the hard way ;-)

(though this was several years ago, and ntfs-3g might have been patched
in the mean time to no longer support that, but I have no way of testing
anymore...)

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Debian part of a version number when epoch is bumped

[Colin Watson]

On Wed, Feb 07, 2018 at 01:57:03PM +0100, Christian T. Steigies wrote:
> I did not know that I can upload an orig.tar.* with a debian-version
> >1, nor did I know that I was supposed to workaround bugs in Ubuntu or
> filesystems that can not handle epochs.

Once again, I dispute that this is a bug in Ubuntu.  We just have
somewhat more stringent checks for duplicate file names, which any other
derivative or indeed dak itself might easily also have (indeed, dak does
check exactly this kind of thing, but has a shorter memory).

> If this becomes policy, I guess I need to skip 10 debian versions (probably
> purging my last upload from the archives is not possible). How should I do
> that correctly, without attracting another bug report? Should I just skip
> debian version -2 to -11, should they be mentioned in the changelog but
> never uploaded, or what it the accepted solution?

Simply jumping back to -12 seems perfectly reasonable; there's no need
for fake changelog entries.  There's no requirement to increment
versions one by one.

-- 
Colin Watson   [cjwat...@debian.org]

Re: Debian part of a version number when epoch is bumped

[Ian Jackson]

Christian T. Steigies writes ("Re: Debian part of a version number when epoch 
is bumped"):
> This should be documented somewhere where a regular DD can easily learn
> about these restrictions. Looking at the debian-policy, I still do not see
> what I did wrong with my recent upload:
> 
> https://www.debian.org/doc/debian-policy/
> 
>  5.6.12. Version
>  The version number of a package. The format is:
>  [epoch:]upstream_version[-debian_revision].
> 
>  The three components here are:
> 
>  epoch
>  This is a single (generally small) unsigned integer. It may be omitted, in
>  which case zero is assumed. If it is omitted then the upstream_version may
>  not contain any colons.

I suggest something like this wording to replace the following
paragraphs about the epoch:

   Epochs exist to cope with changes to the upstream version numbering
   scheme, and some other difficult cases.  The epoch is a powerful
   tool, but increasing the epoch it has downsides and should be
   avoided when possible.

   If you think you need to increase the epoch for a package, please
   consult debian-devel first.

Ian.

Re: Debian part of a version number when epoch is bumped

[Christian T. Steigies]

Moin,
On Wed, Feb 07, 2018 at 12:25:10PM +0100, Raphael Hertzog wrote:
> Hi,
> 
> On Wed, 07 Feb 2018, Chris Lamb wrote:
> > Could you please file bugs for these issues? Many thanks. 
> 
> Done:
> 
> - https://bugs.debian.org/889814 
>   Improve long description of epoch-change-without-comment
>   => Additional suggestions to put in the long description are welcome.
> 
> - https://bugs.debian.org/889816
>   Complain when epoch has been bumped but upstream version did not go 
> backwards

This should be documented somewhere where a regular DD can easily learn
about these restrictions. Looking at the debian-policy, I still do not see
what I did wrong with my recent upload:

https://www.debian.org/doc/debian-policy/

 5.6.12. Version
 The version number of a package. The format is:
 [epoch:]upstream_version[-debian_revision].

 The three components here are:

 epoch
 This is a single (generally small) unsigned integer. It may be omitted, in
 which case zero is assumed. If it is omitted then the upstream_version may
 not contain any colons.

 It is provided to allow mistakes in the version numbers of older versions of
 a package, and also a package?s previous version numbering schemes, to be
 left behind.
 [...]
 Note that the purpose of epochs is to allow us to leave behind mistakes in
 version numbering, and to cope with situations where the version numbering
 scheme changes. It is not intended to cope with version numbers containing
 strings of letters which the package management system cannot interpret
 (such as ALPHA or pre-), or with silly orderings. [8]


I did a mistake when I uploaded this version as a native package in 2006. 
Unfortunately there have been no new upstream releases since, and there wont
be.  The upstream source consisted of two tarballs, which I shipped as one
containing the two.  The package received a bug to drop esound support, this
was a good opportunity to repackage everything from scratch with a simple dh
rule, and drop the no longer needed esound tarball.  I did not know that I
can upload an orig.tar.* with a debian-version >1, nor did I know that I was
supposed to workaround bugs in Ubuntu or filesystems that can not handle
epochs.  Please document this, not only in lintian.

If this becomes policy, I guess I need to skip 10 debian versions (probably
purging my last upload from the archives is not possible). How should I do
that correctly, without attracting another bug report? Should I just skip
debian version -2 to -11, should they be mentioned in the changelog but
never uploaded, or what it the accepted solution?

Christian

Re: Debian part of a version number when epoch is bumped

[Michael Stone]

On Wed, Feb 07, 2018 at 09:18:03AM +, Jonathan McDowell wrote:

On Tue, Feb 06, 2018 at 10:19:25PM +, Colin Watson wrote:

On Tue, Feb 06, 2018 at 12:28:54PM +0100, Mattia Rizzolo wrote:
> On Tue, Feb 06, 2018 at 08:37:44AM +, Colin Watson wrote:
> > I disagree - reusing file names with different contents in a
> > Debian-format archive is IMO always wrong regardless of the time elapsed
> > between uses - but it's unlikely to be worth arguing.
>
> Do you happen to know what was the reason somebody way back in time
> decided to not consider the epoch in the filenames?

My understanding is that it would have caused some kind of problems for
common operations at the time involving things like tar, but I'm afraid
I forget the details.  Ian Jackson would probably know ...


You can't put a : in a filename on a FAT filesystem.


And it was the directory delimiter character in HFS, so :'s still have 
weird behavior in OS X.


Mike Stone

Re: Debian part of a version number when epoch is bumped

[Raphael Hertzog]

Hi,

On Wed, 07 Feb 2018, Chris Lamb wrote:
> Could you please file bugs for these issues? Many thanks. 

Done:

- https://bugs.debian.org/889814 
  Improve long description of epoch-change-without-comment
  => Additional suggestions to put in the long description are welcome.

- https://bugs.debian.org/889816
  Complain when epoch has been bumped but upstream version did not go backwards

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Debian part of a version number when epoch is bumped

[Chris Lamb]

Hi Raphael, 

> [..] 

Could you please file bugs for these issues? Many thanks. 


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Debian part of a version number when epoch is bumped

[Jonathan McDowell]

On Tue, Feb 06, 2018 at 10:19:25PM +, Colin Watson wrote:
> On Tue, Feb 06, 2018 at 12:28:54PM +0100, Mattia Rizzolo wrote:
> > On Tue, Feb 06, 2018 at 08:37:44AM +, Colin Watson wrote:
> > > I disagree - reusing file names with different contents in a
> > > Debian-format archive is IMO always wrong regardless of the time elapsed
> > > between uses - but it's unlikely to be worth arguing.
> > 
> > Do you happen to know what was the reason somebody way back in time
> > decided to not consider the epoch in the filenames?
> 
> My understanding is that it would have caused some kind of problems for
> common operations at the time involving things like tar, but I'm afraid
> I forget the details.  Ian Jackson would probably know ...

You can't put a : in a filename on a FAT filesystem.

J.

-- 
... Purranoia: The fear that your cat is up to something.

Re: Debian part of a version number when epoch is bumped

[Raphael Hertzog]

Hi,

On Tue, 06 Feb 2018, Chris Lamb wrote:
> (The long description could make more scary noises about bumping,
> however.)

And include an explanation of when it's appropriate or not, and of
ways to avoid it altogether...

Please someone do it and add that to the auto-reject list.

And also add a tag which complains even more loudly when you bump the
epoch and when the upstream version does not go backwards. i.e.
switching from 1:X to 2:Y would complain if Y > X.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Debian part of a version number when epoch is bumped

[Colin Watson]

On Tue, Feb 06, 2018 at 12:28:54PM +0100, Mattia Rizzolo wrote:
> On Tue, Feb 06, 2018 at 08:37:44AM +, Colin Watson wrote:
> > I disagree - reusing file names with different contents in a
> > Debian-format archive is IMO always wrong regardless of the time elapsed
> > between uses - but it's unlikely to be worth arguing.
> 
> Do you happen to know what was the reason somebody way back in time
> decided to not consider the epoch in the filenames?

My understanding is that it would have caused some kind of problems for
common operations at the time involving things like tar, but I'm afraid
I forget the details.  Ian Jackson would probably know ...

-- 
Colin Watson   [cjwat...@debian.org]

Re: Debian part of a version number when epoch is bumped

[Chris Lamb]

Mattia Rizzolo wrote:

> > Maybe introducing epochs should force a round-trip through NEW...
> 
> Suggested and rejected: https://bugs.debian.org/860797

Somewhat related..  Since version 2.5.61, Lintian warns about epoch
changes that are not mentioned in the changelog which should capture
any accidental bump and requires a maintainer to to justify — or at
least think twice about! — a deliberate one.

(The long description could make more scary noises about bumping,
however.)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Debian part of a version number when epoch is bumped

[Holger Levsen]

On Tue, Feb 06, 2018 at 03:34:50PM +0200, Lars Wirzenius wrote:
> That would completely ruin my plan to only ever release version 1.0 of
> all of my future projects, but increase the epoch instead.

you are very evil indeed.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: Debian part of a version number when epoch is bumped

[Mattia Rizzolo]

On Tue, Feb 06, 2018 at 01:37:43PM +, Steve McIntyre wrote:
> Colin Watson wrote:
> >On Mon, Feb 05, 2018 at 05:06:00PM +0100, Mattia Rizzolo wrote:
> >> On Mon, Feb 05, 2018 at 10:43:17AM -0500, Jeremy Bicha wrote:
> >> > and the version number issue is only an Ubuntu-specific problem (given
> >> > that the original 1.0.51-1 was superseded in 2006).
> >> 
> >> I agree this is an Ubuntu issue with their infrastructure.
> >
> >I disagree - reusing file names with different contents in a
> >Debian-format archive is IMO always wrong regardless of the time elapsed
> >between uses - but it's unlikely to be worth arguing.
> 
> Agreed 100%. This continues to cause problems for other consumers of
> the Debian archive, not just the Ubuntu infrastructure.

BTW, making epoch part of the filename was rejected by the debian
archive admins: https://bugs.debian.org/645895

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Debian part of a version number when epoch is bumped

[Mattia Rizzolo]

On Tue, Feb 06, 2018 at 01:31:17PM +, Jonathan Dowland wrote:
> On Mon, Feb 05, 2018 at 05:06:00PM +0100, Mattia Rizzolo wrote:
> > This is one of the many situations where I'd like developers to *ask*
> > when unsure or uncertain of something.
> > So, in fact, the epoch bump was totally useless, and as it often happens
> > in those cases, it's causing headaches for somebody.
> 
> Maybe introducing epochs should force a round-trip through NEW...

Suggested and rejected: https://bugs.debian.org/860797

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Debian part of a version number when epoch is bumped

[Steve McIntyre]

Colin Watson wrote:
>On Mon, Feb 05, 2018 at 05:06:00PM +0100, Mattia Rizzolo wrote:
>> On Mon, Feb 05, 2018 at 10:43:17AM -0500, Jeremy Bicha wrote:
>> > and the version number issue is only an Ubuntu-specific problem (given
>> > that the original 1.0.51-1 was superseded in 2006).
>> 
>> I agree this is an Ubuntu issue with their infrastructure.
>
>I disagree - reusing file names with different contents in a
>Debian-format archive is IMO always wrong regardless of the time elapsed
>between uses - but it's unlikely to be worth arguing.

Agreed 100%. This continues to cause problems for other consumers of
the Debian archive, not just the Ubuntu infrastructure.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I suspect most samba developers are already technically insane... Of
 course, since many of them are Australians, you can't tell." -- Linus Torvalds

Re: Debian part of a version number when epoch is bumped

[Lars Wirzenius]

On Tue, 2018-02-06 at 13:31 +, Jonathan Dowland wrote:
> On Mon, Feb 05, 2018 at 05:06:00PM +0100, Mattia Rizzolo wrote:
> > This is one of the many situations where I'd like developers to *ask*
> > when unsure or uncertain of something.
> > So, in fact, the epoch bump was totally useless, and as it often happens
> > in those cases, it's causing headaches for somebody.
> 
> Maybe introducing epochs should force a round-trip through NEW...

That would completely ruin my plan to only ever release version 1.0 of
all of my future projects, but increase the epoch instead.

signature.asc
Description: This is a digitally signed message part

Re: Debian part of a version number when epoch is bumped

[Jonathan Dowland]

On Mon, Feb 05, 2018 at 05:06:00PM +0100, Mattia Rizzolo wrote:

This is one of the many situations where I'd like developers to *ask*
when unsure or uncertain of something.
So, in fact, the epoch bump was totally useless, and as it often happens
in those cases, it's causing headaches for somebody.


Maybe introducing epochs should force a round-trip through NEW...


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Debian part of a version number when epoch is bumped

[Mattia Rizzolo]

On Tue, Feb 06, 2018 at 08:37:44AM +, Colin Watson wrote:
> I disagree - reusing file names with different contents in a
> Debian-format archive is IMO always wrong regardless of the time elapsed
> between uses - but it's unlikely to be worth arguing.

Do you happen to know what was the reason somebody way back in time
decided to not consider the epoch in the filenames?

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Debian part of a version number when epoch is bumped

[Colin Watson]

On Mon, Feb 05, 2018 at 05:06:00PM +0100, Mattia Rizzolo wrote:
> On Mon, Feb 05, 2018 at 10:43:17AM -0500, Jeremy Bicha wrote:
> > and the version number issue is only an Ubuntu-specific problem (given
> > that the original 1.0.51-1 was superseded in 2006).
> 
> I agree this is an Ubuntu issue with their infrastructure.

I disagree - reusing file names with different contents in a
Debian-format archive is IMO always wrong regardless of the time elapsed
between uses - but it's unlikely to be worth arguing.

> Have you tried asking the ubuntu archive admins, maybe they could get it
> through manually?

There's no such facility.  The only way is to bump the version in some
way so that there are no collisions.

-- 
Colin Watson   [cjwat...@debian.org]

Re: Debian part of a version number when epoch is bumped

[Mattia Rizzolo]

On Mon, Feb 05, 2018 at 10:43:17AM -0500, Jeremy Bicha wrote:
> moon-buggy recently had its epoch bumped. The old version is
> 1.0.51-11, the new version is 1:1.0.51-1. I opened
> https://bugs.debian.org/887740


Sigh.
Indeed he had no reason to bump the epoch.
He couldn't see solutions, but the truth is that all he had to do was to
switch to 3.0 (quilt) with the -12 upload and clean up its sources.
moon-buggy_1.0.51.orig.tar.gz had never been uploaded, and even if it
was the epoch would have not allowed him to replace it as the upstream
version doesn't change with epoch changes.
This is one of the many situations where I'd like developers to *ask*
when unsure or uncertain of something.
So, in fact, the epoch bump was totally useless, and as it often happens
in those cases, it's causing headaches for somebody.


> The maintainer thinks the 1:1.0.51-12 version number would be "ugly"

Well, for sure bumping -1 → -12 is ugly...

> and the version number issue is only an Ubuntu-specific problem (given
> that the original 1.0.51-1 was superseded in 2006).

I agree this is an Ubuntu issue with their infrastructure.
Have you tried asking the ubuntu archive admins, maybe they could get it
through manually?

> I could not find anywhere in Debian Policy that directly addressed
> this issue.

Please don't consider the Debian Policy like a stick.  Or a all-kwowing
never-wrong oracle.

> Therefore, I'm bring up this issue here to get input from other
> developers.

If I were the maintainer, I'd just bump the version to get it through
LP, but I'm biased as I'm also a Ubuntu developer.
Otherwise, just manually merge it, doing the 1.0 native → 3.0 quilt move
properly?  Just that then the version are not going to match anymore for
a long while, and MoM is surely going to be confused…

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Debian part of a version number when epoch is bumped

[Matt Zagrabelny]

On Mon, Feb 5, 2018 at 9:43 AM, Jeremy Bicha  wrote:

>
> The maintainer thinks the 1:1.0.51-12 version number would be "ugly"


The maintainer would not be wrong.

-m