[prev in list] [next in list] [prev in thread] [next in thread] 

List:       debian-devel
Subject:    Re: Debian part of a version number when epoch is bumped
From:       Thibaut Paumard <thibaut () debian ! org>
Date:       2018-02-15 9:58:01
Message-ID: 559cafdb-0ad1-abfb-7240-2da7d5869a6b () debian ! org
[Download RAW message or body]

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.

[prev in list] [next in list] [prev in thread] [next in thread]