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