Debian part of a version number when epoch is bumped

classic Classic list List threaded Threaded
102 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

Debian part of a version number when epoch is bumped

Jeremy Bicha-5
Hi,

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 to request that the version number be
bumped to 1:1.0.51-12.

The problem with the 1:1.0.51-1 version number is that the Debian
source filenames like the .dsc do not include the epoch in the
filename. This means that is impossible to include the completely
history of files in the same directory (because there would be files
with the same file name but different file contents). This also means
that it is impossible to auto-sync the package to Ubuntu.

The maintainer thinks the 1:1.0.51-12 version number would be "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 could not find
anywhere in Debian Policy that directly addressed this issue.
Therefore, I'm bring up this issue here to get input from other
developers.

Thanks,
Jeremy Bicha

Reply | Threaded
Open this post in threaded view
|

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

Matt Zagrabelny


On Mon, Feb 5, 2018 at 9:43 AM, Jeremy Bicha <[hidden email]> wrote:

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

The maintainer would not be wrong.

-m 

Reply | Threaded
Open this post in threaded view
|

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

Mattia Rizzolo-5
In reply to this post by Jeremy Bicha-5
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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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                                       [[hidden email]]

Reply | Threaded
Open this post in threaded view
|

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

Mattia Rizzolo-5
On Tue, Feb 06, 2018 at 08:37:44AM +0000, 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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Jonathan Dowland
In reply to this post by Mattia Rizzolo-5
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.

Reply | Threaded
Open this post in threaded view
|

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

Lars Wirzenius-5
On Tue, 2018-02-06 at 13:31 +0000, 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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Steve McIntyre
In reply to this post by Colin Watson
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.                                [hidden email]
"I suspect most samba developers are already technically insane... Of
 course, since many of them are Australians, you can't tell." -- Linus Torvalds

Reply | Threaded
Open this post in threaded view
|

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

Mattia Rizzolo-5
In reply to this post by Jonathan Dowland
On Tue, Feb 06, 2018 at 01:31:17PM +0000, 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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Mattia Rizzolo-5
In reply to this post by Steve McIntyre
On Tue, Feb 06, 2018 at 01:37:43PM +0000, 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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Holger Levsen-2
In reply to this post by Lars Wirzenius-5
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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Chris Lamb -2
In reply to this post by Mattia Rizzolo-5
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
     `. `'`      [hidden email] / chris-lamb.co.uk
       `-

Reply | Threaded
Open this post in threaded view
|

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

Colin Watson
In reply to this post by Mattia Rizzolo-5
On Tue, Feb 06, 2018 at 12:28:54PM +0100, Mattia Rizzolo wrote:
> On Tue, Feb 06, 2018 at 08:37:44AM +0000, 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                                       [[hidden email]]

Reply | Threaded
Open this post in threaded view
|

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

Jonathan McDowell-3
On Tue, Feb 06, 2018 at 10:19:25PM +0000, 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 +0000, 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.

Reply | Threaded
Open this post in threaded view
|

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

Raphael Hertzog-3
In reply to this post by Chris Lamb -2
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/

Reply | Threaded
Open this post in threaded view
|

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

Chris Lamb -2
Hi Raphael,

> [..]

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


Regards,

--
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      [hidden email] / chris-lamb.co.uk
       `-

Reply | Threaded
Open this post in threaded view
|

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

Raphael Hertzog-3
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/

Reply | Threaded
Open this post in threaded view
|

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

Michael Stone-2
In reply to this post by Jonathan McDowell-3
On Wed, Feb 07, 2018 at 09:18:03AM +0000, Jonathan McDowell wrote:

>On Tue, Feb 06, 2018 at 10:19:25PM +0000, 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 +0000, 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

Reply | Threaded
Open this post in threaded view
|

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

Christian T. Steigies
In reply to this post by Raphael Hertzog-3
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

Reply | Threaded
Open this post in threaded view
|

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

Ian Jackson-2
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.

1234 ... 6