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 6
On Wed, Feb 14, 2018 at 02:41:37PM -0600, Matt Zagrabelny wrote:
> On Wed, Feb 14, 2018 at 2:15 PM, Michael Stone wrote:
> > On Wed, Feb 14, 2018 at 09:05:05PM +0100, Vincent Bernat wrote:
> >
> >> In the example above, while in Wheezy, the dependency was perfectly
> >> correct. It became wrong be
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 cre
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 dif
Michael Stone writes:
> On Wed, Feb 14, 2018 at 01:38:53PM -0800, Russ Allbery wrote:
>>> Another way to think of it is that the epoch should really be evaluated
>>> as part of the package name rather than the version string--it's
>>> basically a mechanism to avoid renaming a package for purely a
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 ha
Michael Stone writes:
> I don't think you'd need to change the package metadata for this, just
> change the comparison rules. I'm not entirely sure what the semantics
> should be, though--a simple depends >= is easy, but what about conflicts
> and breaks with < worth.
Yeah, that would work too,
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 o
Michael Stone writes:
> That doesn't matter. The fundamental problem was that it's impossible to
> predict that a future package would have an older version of the
> software with a newer name. Whether that's done with an epoch that
> (horrors!) won't go away or because someone creates a crazy ve
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 c
On Wed, Feb 14, 2018 at 2:15 PM, Michael Stone wrote:
> On Wed, Feb 14, 2018 at 09:05:05PM +0100, Vincent Bernat wrote:
>
>> In the example above, while in Wheezy, the dependency was perfectly
>> correct. It became wrong because of the epoch bump (for no obvious
>> reason). For software we distri
On Wed, Feb 14, 2018 at 09:24:04PM +0100, Vincent Bernat wrote:
❦ 14 février 2018 15:15 -0500, Michael Stone :
In the example above, while in Wheezy, the dependency was perfectly
correct. It became wrong because of the epoch bump (for no obvious
reason). For software we distribute ourselves, t
❦ 14 février 2018 15:15 -0500, Michael Stone :
>>In the example above, while in Wheezy, the dependency was perfectly
>>correct. It became wrong because of the epoch bump (for no obvious
>>reason). For software we distribute ourselves, this change can be caught
>>at some point before the release
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
❦ 14 février 2018 21:11 +0200, Lars Wirzenius :
>> > > > It's not only an infrastructure problem. If you Depends on X (>= 1.8),
>> > > > this will be true with X 1:1.6 as well.
> ...
>> That's exactly the point. You wanted X >= 1.8 and you get X 1.6.
>
> I don't think that's what you said, or at
On Wed, 2018-02-14 at 18:52 +0100, Vincent Bernat wrote:
> ❦ 14 février 2018 16:09 +0200, Lars Wirzenius :
>
> > > > It's not only an infrastructure problem. If you Depends on X (>= 1.8),
> > > > this will be true with X 1:1.6 as well.
...
> That's exactly the point. You wanted X >= 1.8 and you
❦ 14 février 2018 16:09 +0200, Lars Wirzenius :
>> > It's not only an infrastructure problem. If you Depends on X (>= 1.8),
>> > this will be true with X 1:1.6 as well.
>>
>> Only if your program is severely buggy.
>>
>> Hint: either it matches dpkg --compare-versions exactly, or it is a
>> se
On Wed, 14 Feb 2018 16:29:20 +0100, Michael Biebl
wrote:
>Am 14.02.2018 um 16:08 schrieb Andrey Rahmatullin:
>> On Wed, Feb 14, 2018 at 01:57:16PM +0100, Vincent Bernat wrote:
>>> It's not only an infrastructure problem. If you Depends on X (>= 1.8),
>>> this will be true with X 1:1.6 as well.
>>
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
Am 14.02.2018 um 14:31 schrieb Jeremy Bicha:
> On Wed, Feb 14, 2018 at 7:57 AM, Vincent Bernat wrote:
>> ❦ 14 février 2018 12:53 +0100, Wouter Verhelst :
>>
> Would it hurt to take those epoch bumps into Debian?
Depends on what you mean by hurt. I see epochs being used w/o much
>>>
Am 14.02.2018 um 16:08 schrieb Andrey Rahmatullin:
> On Wed, Feb 14, 2018 at 01:57:16PM +0100, Vincent Bernat wrote:
>> It's not only an infrastructure problem. If you Depends on X (>= 1.8),
>> this will be true with X 1:1.6 as well.
> Or with 1.8+really1.6.
But this problem will fix itself (after
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
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.
T
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 cas
On Wed, Feb 14, 2018 at 01:57:16PM +0100, Vincent Bernat wrote:
> ❦ 14 février 2018 12:53 +0100, Wouter Verhelst :
>
> >> > Would it hurt to take those epoch bumps into Debian?
> >>
> >> Depends on what you mean by hurt. I see epochs being used w/o much
> >> tought or care, on many situations w
On Wed, 2018-02-14 at 11:54 -0200, Henrique de Moraes Holschuh wrote:
> On Wed, 14 Feb 2018, Vincent Bernat wrote:
> > It's not only an infrastructure problem. If you Depends on X (>= 1.8),
> > this will be true with X 1:1.6 as well.
>
> Only if your program is severely buggy.
>
> Hint: either it
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 nee
On Wed, 14 Feb 2018, Vincent Bernat wrote:
> ❦ 14 février 2018 12:53 +0100, Wouter Verhelst :
> >> > Would it hurt to take those epoch bumps into Debian?
> >>
> >> Depends on what you mean by hurt. I see epochs being used w/o much
> >> tought or care, on many situations where they are not suppos
On Wed, Feb 14, 2018 at 7:57 AM, Vincent Bernat wrote:
> ❦ 14 février 2018 12:53 +0100, Wouter Verhelst :
>
>>> > Would it hurt to take those epoch bumps into Debian?
>>>
>>> Depends on what you mean by hurt. I see epochs being used w/o much
>>> tought or care, on many situations where they are
❦ 14 février 2018 12:53 +0100, Wouter Verhelst :
>> > Would it hurt to take those epoch bumps into Debian?
>>
>> Depends on what you mean by hurt. I see epochs being used w/o much
>> tought or care, on many situations where they are not supposed to be
>> used, and they are permanent stigmas.
>
On Mon, Feb 12, 2018 at 03:23:14AM +0100, Guillem Jover wrote:
> On Fri, 2018-02-09 at 14:35:15 -0500, Jeremy Bicha wrote:
> > On Fri, Feb 9, 2018 at 2:22 PM, Andrey Rahmatullin wrote:
> > > On Fri, Feb 09, 2018 at 06:58:49PM +0100, Philipp Kern wrote:
> > >> If Ubuntu uses an epoch without Debian
31 matches
Mail list logo
