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

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

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

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

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

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

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

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,

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

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,

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

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"

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

> 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

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

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

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

❦ 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

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

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

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

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

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

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],

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

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

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

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

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

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"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

❦ 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

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

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

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

❦ 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

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

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

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

❦ 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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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,

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

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

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

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

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

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

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

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

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

❦ 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

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

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

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

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

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

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

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

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 remotel

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

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:

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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 ver

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

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 d

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

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.

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

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 >

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

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

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

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 >

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

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

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

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 ;-)

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1   2   >