Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #84135 > unrolled thread

Debian part of a version number when epoch is bumped

Back to article view | Back to linux.debian.devel

Contents

  Debian part of a version number when epoch is bumped Jeremy Bicha <jbicha@debian.org> - 2018-02-05 16:50 +0100
    Re: Debian part of a version number when epoch is bumped Matt Zagrabelny <mzagrabe@d.umn.edu> - 2018-02-05 17:00 +0100
    Re: Debian part of a version number when epoch is bumped Mattia Rizzolo <mattia@debian.org> - 2018-02-05 17:10 +0100
      Re: Debian part of a version number when epoch is bumped Colin Watson <cjwatson@debian.org> - 2018-02-06 09:40 +0100
        Re: Debian part of a version number when epoch is bumped Mattia Rizzolo <mattia@debian.org> - 2018-02-06 14:30 +0100
          Re: Debian part of a version number when epoch is bumped Colin Watson <cjwatson@debian.org> - 2018-02-06 23:30 +0100
            Re: Debian part of a version number when epoch is bumped Michael Stone <mstone@debian.org> - 2018-02-07 13:20 +0100
            Re: Debian part of a version number when epoch is bumped Jonathan McDowell <noodles@earth.li> - 2018-02-07 11:10 +0100
              Re: Debian part of a version number when epoch is bumped Wouter Verhelst <wouter@debian.org> - 2018-02-07 18:00 +0100
            Re: Debian part of a version number when epoch is bumped Seth Arnold <seth.arnold@canonical.com> - 2018-02-08 00:50 +0100
              Re: Debian part of a version number when epoch is bumped Ian Jackson <ijackson@chiark.greenend.org.uk> - 2018-02-09 13:10 +0100
                Re: Debian part of a version number when epoch is bumped Philipp Kern <pkern@debian.org> - 2018-02-09 13:50 +0100
                  Re: Debian part of a version number when epoch is bumped Ian Jackson <ijackson@chiark.greenend.org.uk> - 2018-02-09 17:10 +0100
                    Re: Debian part of a version number when epoch is bumped Colin Watson <cjwatson@debian.org> - 2018-02-09 18:20 +0100
                    Re: Debian part of a version number when epoch is bumped Philipp Kern <pkern@debian.org> - 2018-02-09 18:20 +0100
                      Re: Debian part of a version number when epoch is bumped Russ Allbery <rra@debian.org> - 2018-02-09 18:30 +0100
                        Re: Debian part of a version number when epoch is bumped Philipp Kern <pkern@debian.org> - 2018-02-09 19:00 +0100
                          Re: Debian part of a version number when epoch is bumped Russ Allbery <rra@debian.org> - 2018-02-09 19:20 +0100
                          Re: Debian part of a version number when epoch is bumped Andrey Rahmatullin <wrar@debian.org> - 2018-02-09 20:30 +0100
                            Re: Debian part of a version number when epoch is bumped Jeremy Bicha <jbicha@debian.org> - 2018-02-09 20:40 +0100
                              Re: Debian part of a version number when epoch is bumped Guillem Jover <guillem@debian.org> - 2018-02-12 03:30 +0100
                                Re: Debian part of a version number when epoch is bumped Wouter Verhelst <wouter@debian.org> - 2018-02-14 13:00 +0100
                                  Re: Debian part of a version number when epoch is bumped Vincent Bernat <bernat@debian.org> - 2018-02-14 14:00 +0100
                                    Re: Debian part of a version number when epoch is bumped Jeremy Bicha <jbicha@ubuntu.com> - 2018-02-14 14:50 +0100
                                      Re: Debian part of a version number when epoch is bumped Michael Biebl <biebl@debian.org> - 2018-02-14 16:40 +0100
                                    Re: Debian part of a version number when epoch is bumped Henrique de Moraes Holschuh <hmh@debian.org> - 2018-02-14 15:00 +0100
                                      Re: Debian part of a version number when epoch is bumped Lars Wirzenius <liw@liw.fi> - 2018-02-14 15:20 +0100
                                        Re: Debian part of a version number when epoch is bumped Vincent Bernat <bernat@debian.org> - 2018-02-14 19:00 +0100
                                          Re: Debian part of a version number when epoch is bumped Lars Wirzenius <liw@liw.fi> - 2018-02-14 20:30 +0100
                                            Re: Debian part of a version number when epoch is bumped Vincent Bernat <bernat@debian.org> - 2018-02-14 21:10 +0100
                                              Re: Debian part of a version number when epoch is bumped Michael Stone <mstone@debian.org> - 2018-02-14 21:20 +0100
                                                Re: Debian part of a version number when epoch is bumped Vincent Bernat <bernat@debian.org> - 2018-02-14 21:30 +0100
                                                  Re: Debian part of a version number when epoch is bumped Michael Stone <mstone@debian.org> - 2018-02-14 21:40 +0100
                                                    Re: Debian part of a version number when epoch is bumped Russ Allbery <rra@debian.org> - 2018-02-14 22:00 +0100
                                                      Re: Debian part of a version number when epoch is bumped Michael Stone <mstone@debian.org> - 2018-02-14 22:30 +0100
                                                        Re: Debian part of a version number when epoch is bumped Russ Allbery <rra@debian.org> - 2018-02-14 22:40 +0100
                                                          Re: Debian part of a version number when epoch is bumped Michael Stone <mstone@debian.org> - 2018-02-14 23:10 +0100
                                                            Re: Debian part of a version number when epoch is bumped Russ Allbery <rra@debian.org> - 2018-02-14 23:20 +0100
                                                              Re: Debian part of a version number when epoch is bumped Michael Stone <mstone@debian.org> - 2018-02-14 23:40 +0100
                                                        Re: Debian part of a version number when epoch is bumped Wouter Verhelst <wouter@debian.org> - 2018-02-15 11:20 +0100
                                                          Re: Debian part of a version number when epoch is bumped Simon McVittie <smcv@debian.org> - 2018-02-15 11:50 +0100
                                                            Re: Debian part of a version number when epoch is bumped Wouter Verhelst <wouter@debian.org> - 2018-02-15 12:30 +0100
                                                            Re: Debian part of a version number when epoch is bumped Thibaut Paumard <thibaut@debian.org> - 2018-02-15 13:30 +0100
                                                            Re: Debian part of a version number when epoch is bumped Vincent Ladeuil <v.ladeuil+debian@free.fr> - 2018-02-15 15:10 +0100
                                                      Re: Debian part of a version number when epoch is bumped Guillem Jover <guillem@debian.org> - 2018-02-16 03:10 +0100
                                                        Re: Debian part of a version number when epoch is bumped Dimitri John Ledkov <xnox@debian.org> - 2018-03-12 12:40 +0100
                                                          Re: Debian part of a version number when epoch is bumped Cédric Boutillier <boutil@debian.org> - 2018-03-12 18:50 +0100
                                                    Re: Debian part of a version number when epoch is bumped Simon McVittie <smcv@debian.org> - 2018-02-15 01:00 +0100
                                                Re: Debian part of a version number when epoch is bumped Michael Stone <mstone@debian.org> - 2018-02-14 21:50 +0100
                                                Re: Debian part of a version number when epoch is bumped Matt Zagrabelny <mzagrabe@d.umn.edu> - 2018-02-14 21:50 +0100
                                                  Re: Debian part of a version number when epoch is bumped Adam Borowski <kilobyte@angband.pl> - 2018-02-15 08:50 +0100
                                                    Re: Debian part of a version number when epoch is bumped gregor herrmann <gregoa@debian.org> - 2018-02-15 09:00 +0100
                                                      Re: Debian part of a version number when epoch is bumped Adam Borowski <kilobyte@angband.pl> - 2018-02-15 09:30 +0100
                                          Re: Debian part of a version number when epoch is bumped Thibaut Paumard <thibaut@debian.org> - 2018-02-15 11:20 +0100
                                            Re: Debian part of a version number when epoch is bumped gregor herrmann <gregoa@debian.org> - 2018-02-15 13:10 +0100
                                              Re: Debian part of a version number when epoch is bumped Thibaut Paumard <thibaut@debian.org> - 2018-02-15 13:40 +0100
                                                Re: Debian part of a version number when epoch is bumped Vincent Bernat <bernat@debian.org> - 2018-02-15 14:20 +0100
                                                  Re: Debian part of a version number when epoch is bumped Thibaut Paumard <thibaut@debian.org> - 2018-02-15 15:30 +0100
                                            Re: Debian part of a version number when epoch is bumped Michael Stone <mstone@debian.org> - 2018-02-15 14:20 +0100
                                    Re: Debian part of a version number when epoch is bumped Wouter Verhelst <wouter@debian.org> - 2018-02-14 15:50 +0100
                                      Re: Debian part of a version number when epoch is bumped Raphael Hertzog <hertzog@debian.org> - 2018-02-14 16:10 +0100
                                    Re: Debian part of a version number when epoch is bumped Andrey Rahmatullin <wrar@debian.org> - 2018-02-14 16:10 +0100
                                      Re: Debian part of a version number when epoch is bumped Michael Biebl <biebl@debian.org> - 2018-02-14 16:30 +0100
                                        Re: Debian part of a version number when epoch is bumped Andrey Rahmatullin <wrar@debian.org> - 2018-02-14 17:10 +0100
                                        Re: Debian part of a version number when epoch is bumped Marc Haber <mh+debian-devel@zugschlus.de> - 2018-02-14 18:30 +0100
                                        Re: Debian part of a version number when epoch is bumped Wouter Verhelst <wouter@debian.org> - 2018-02-15 11:20 +0100
                                  Re: Debian part of a version number when epoch is bumped Steve McIntyre <steve@einval.com> - 2018-02-14 15:10 +0100
                                  Re: Debian part of a version number when epoch is bumped Ian Campbell <ijc@debian.org> - 2018-02-14 15:50 +0100
                      Re: Debian part of a version number when epoch is bumped Ian Jackson <ijackson@chiark.greenend.org.uk> - 2018-02-09 19:40 +0100
                      Re: Debian part of a version number when epoch is bumped Guillem Jover <guillem@debian.org> - 2018-02-12 03:20 +0100
        Re: Debian part of a version number when epoch is bumped Steve McIntyre <steve@einval.com> - 2018-02-06 14:40 +0100
          Re: Debian part of a version number when epoch is bumped Mattia Rizzolo <mattia@debian.org> - 2018-02-06 15:00 +0100
      Re: Debian part of a version number when epoch is bumped Lars Wirzenius <liw@liw.fi> - 2018-02-06 14:40 +0100
        Re: Debian part of a version number when epoch is bumped Holger Levsen <holger@layer-acht.org> - 2018-02-06 15:20 +0100
        Re: Debian part of a version number when epoch is bumped Jonathan Dowland <jmtd@debian.org> - 2018-02-12 09:40 +0100
      Re: Debian part of a version number when epoch is bumped Jonathan Dowland <jmtd@debian.org> - 2018-02-06 14:40 +0100
        Re: Debian part of a version number when epoch is bumped Mattia Rizzolo <mattia@debian.org> - 2018-02-06 15:00 +0100
          Re: Debian part of a version number when epoch is bumped Chris Lamb <lamby@debian.org> - 2018-02-06 16:20 +0100
            Re: Debian part of a version number when epoch is bumped "Christian T. Steigies" <cts@debian.org> - 2018-02-07 14:00 +0100
              Re: Debian part of a version number when epoch is bumped Ian Jackson <ijackson@chiark.greenend.org.uk> - 2018-02-07 15:00 +0100
                Re: Debian part of a version number when epoch is bumped Ian Campbell <ijc@debian.org> - 2018-02-08 11:20 +0100
                  Re: Debian part of a version number when epoch is bumped Raphael Hertzog <hertzog@debian.org> - 2018-02-08 12:00 +0100
                    Re: Debian part of a version number when epoch is bumped Ian Campbell <ijc@debian.org> - 2018-02-09 21:00 +0100
                      Re: Debian part of a version number when epoch is bumped Chris Lamb <lamby@debian.org> - 2018-02-09 23:10 +0100
              Re: Debian part of a version number when epoch is bumped Colin Watson <cjwatson@debian.org> - 2018-02-07 16:40 +0100
            Re: Debian part of a version number when epoch is bumped Raphael Hertzog <hertzog@debian.org> - 2018-02-07 11:00 +0100
              Re: Debian part of a version number when epoch is bumped Chris Lamb <lamby@debian.org> - 2018-02-07 11:50 +0100
                Re: Debian part of a version number when epoch is bumped Raphael Hertzog <hertzog@debian.org> - 2018-02-07 12:30 +0100
      Re: Debian part of a version number when epoch is bumped Jeremy Bicha <jbicha@debian.org> - 2018-03-28 22:20 +0200
        Re: Debian part of a version number when epoch is bumped Chris Lamb <lamby@debian.org> - 2018-03-29 00:00 +0200
        Re: Debian part of a version number when epoch is bumped Adam Borowski <kilobyte@angband.pl> - 2018-03-29 00:30 +0200
        Re: Debian part of a version number when epoch is bumped Mattia Rizzolo <mattia@debian.org> - 2018-03-29 01:00 +0200
        Re: Debian part of a version number when epoch is bumped "Christian T. Steigies" <cts@debian.org> - 2018-03-29 19:10 +0200
          Re: Debian part of a version number when epoch is bumped Simon McVittie <smcv@debian.org> - 2018-03-29 20:00 +0200
          Re: Debian part of a version number when epoch is bumped Adrian Bunk <bunk@debian.org> - 2018-03-30 13:30 +0200
            Re: Debian part of a version number when epoch is bumped "Christian T. Steigies" <cts@debian.org> - 2018-04-02 20:40 +0200
              Re: Debian part of a version number when epoch is bumped Adrian Bunk <bunk@debian.org> - 2018-04-02 21:10 +0200
              Re: Debian part of a version number when epoch is bumped Simon McVittie <smcv@debian.org> - 2018-04-02 21:50 +0200
                Re: Debian part of a version number when epoch is bumped The Wanderer <wanderer@fastmail.fm> - 2018-04-03 05:10 +0200
                  Re: Debian part of a version number when epoch is bumped James McCoy <jamessan@debian.org> - 2018-04-03 05:20 +0200
                Re: Debian part of a version number when epoch is bumped "Christian T. Steigies" <cts@debian.org> - 2018-04-07 20:10 +0200
                  Re: Debian part of a version number when epoch is bumped Ian Jackson <ijackson@chiark.greenend.org.uk> - 2018-04-09 15:30 +0200

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

#84303

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

[toc] | [prev] | [next] | [standalone]

#84304

On Thu, Feb 15, 2018 at 10:41:23AM +0000, 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

[toc] | [prev] | [next] | [standalone]

#84306

(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

[toc] | [prev] | [next] | [standalone]

#84311

>>>>> Simon McVittie <smcv@debian.org> 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.

[toc] | [prev] | [next] | [standalone]

#84325

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:

  <https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_What_are_version_epochs_and_why_and_when_are_they_needed.3F>

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 <mstone@debian.org> 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

[toc] | [prev] | [next] | [standalone]

#85000

On 16 February 2018 at 02:00, Guillem Jover <guillem@debian.org> 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:
>
>   <https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_What_are_version_epochs_and_why_and_when_are_they_needed.3F>
>
> 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. </troll>

[toc] | [prev] | [next] | [standalone]

#85004

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Mon, Mar 12, 2018 at 11:32:17AM +0000, Dimitri John Ledkov wrote:

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

In this case, it means >= 4.0.1 && << 4.1, allowing the last part of the
indicated version number to increase, but not the others.

Best regards,

Cédric

[toc] | [prev] | [next] | [standalone]

#84295

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
<https://lintian.debian.org/tags/experimental-to-unstable-without-comment.html>,
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

[toc] | [prev] | [next] | [standalone]

#84287

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

[toc] | [prev] | [next] | [standalone]

#84288

[Multipart message — attachments visible in raw view] — view raw

On Wed, Feb 14, 2018 at 2:15 PM, Michael Stone <mstone@debian.org> 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

[toc] | [prev] | [next] | [standalone]

#84296

On Wed, Feb 14, 2018 at 02:41:37PM -0600, Matt Zagrabelny wrote:
> On Wed, Feb 14, 2018 at 2:15 PM, Michael Stone <mstone@debian.org> 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!)?

[toc] | [prev] | [next] | [standalone]

#84297

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 

[toc] | [prev] | [next] | [standalone]

#84298

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!)?

[toc] | [prev] | [next] | [standalone]

#84302

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.

[toc] | [prev] | [next] | [standalone]

#84305

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. 

[toc] | [prev] | [next] | [standalone]

#84307

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.

[toc] | [prev] | [next] | [standalone]

#84310

[Multipart message — attachments visible in raw view] — view raw

 ❦ 15 février 2018 13:36 +0100, Thibaut Paumard <thibaut@debian.org> :

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

[toc] | [prev] | [next] | [standalone]

#84313

Le 15/02/2018 à 14:15, Vincent Bernat a écrit :
>   ❦ 15 février 2018 13:36 +0100, Thibaut Paumard <thibaut@debian.org> :
> 
>> 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.

[toc] | [prev] | [next] | [standalone]

#84309

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

[toc] | [prev] | [next] | [standalone]

#84274

On Wed, Feb 14, 2018 at 01:57:16PM +0100, Vincent Bernat wrote:
>  ❦ 14 février 2018 12:53 +0100, Wouter Verhelst <wouter@debian..org> :
> 
> >> > 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

[toc] | [prev] | [next] | [standalone]

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

Back to top | Article view | linux.debian.devel

csiph-web