Re: Why dependency on both default-jre and java-runtime

2017-08-30 Thread Matthias Klose
On 23.08.2017 20:11, Carnë Draug wrote:
> Hi
> 
> I was going through the pkg-java policy and found this [1]:
> 
> Programs must depend on the needed runtime environment
> (default-jre or default-jre-headless if need a GUI or not, and
> java-runtime or java-runtime-headless as provided by
> alternative Java environments).
> 
> However, java-runtime packages are virtual packages provided by
> default-jre so I don't understand why.  Could anyone clarify?

others explained already, here is another reason for the

  default-jre | *-runtime

dependency:  If you have multiple openjdk versions in the archive, during
transition periods and as backports, then this dependency makes sure that you
always get the default dependency.  I have seen a lot of users complaining about
packages pulling in openjdk-9 unintended, which only use *-runtime as a 
dependency.

Matthias



Re: Why dependency on both default-jre and java-runtime

2017-08-29 Thread Carnë Draug
On 25 August 2017 at 15:32, Thorsten Glaser  wrote:
> On Fri, 25 Aug 2017, Carnë Draug wrote:
>
>> dependent on one *and* the other.  That is, that it should have
>> something like this line:
>>
>> Depends: default-jre, java6-runtime
>
> No, that’s definitely wrong. The whole idea is that
> ① you don’t need default-jre but can use a different one that
>   also provides java6-runtime
> ② you can’t Depends just on a virtual package with no real
>   alternative (which must be the first, for a while, for buildds)

Ok.  I looked into some packages and see now that they are not
actually dependent on both.  The policy says "and" but it means that
both should be listed on a list of alternative dependencies.  That's
not really clear but I guess that if it said "or" it could mean that
only of those dependencies need to be listed as dependencies.

I rewrote that paragraph of the policy in the hopes to make it clear
and also explain the reasoning for the alternative [1].  Could someone
please review it?

Thank you
Carnë

[1] 
https://github.com/carandraug/debian-java-policy/commit/bf4eaed67f993c2af7be8fe43f06a4ec7c13ef93



Re: Why dependency on both default-jre and java-runtime

2017-08-25 Thread Thorsten Glaser
On Fri, 25 Aug 2017, Carnë Draug wrote:

> dependent on one *and* the other.  That is, that it should have
> something like this line:
> 
> Depends: default-jre, java6-runtime

No, that’s definitely wrong. The whole idea is that
① you don’t need default-jre but can use a different one that
  also provides java6-runtime
② you can’t Depends just on a virtual package with no real
  alternative (which must be the first, for a while, for buildds)

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

**Besuchen Sie uns auf der dmexco!**
13. und 14. September 2017, Messe Köln,** Halle 7.1, Stand E042**
Digital Marketing Exposition & Conference
[www.tarent.de/dmexco](http://www.tarent.de/dmexco)

Wir empfehlen unseren Vortrag
"Wettbewerbsanalyse im Handel: Preisvergleich online und offline"
am 13. September, 18:00 Uhr im Speaker's Forum / Broadway

*

**Visit us at dmexco!**
September 13th and 14th, 2017, Messe Köln,** Hall 7.1, Booth E042**
Digital Marketing Exposition & Conference
[www.tarent.de/dmexco](http://www.tarent.de/dmexco)

We recommend our presentation
"Competitor analysis in retail: price comparison online and offline"
on September 13th, at 6 pm at the Speaker's Corner / Broadway

*



Re: Why dependency on both default-jre and java-runtime

2017-08-25 Thread Carnë Draug
On 24 August 2017 at 15:17, Bas Couwenberg  wrote:
> On 2017-08-24 16:15, Carnë Draug wrote:
>>
>> Thank you for the answer but I still don't understand.  I get how the
>> use of virtual packages for java-runtime allows one to choose
>> OpenJDK or Oracle JDK.  What I don't understand is the default-jre
>> *and* java-runtime.  Actually, I don't understand the default-jre
>> at all if one also needs to specify a minimum java version via
>> java-runtime.
>
>
> The first package in a list of alternatives must a be real package due to
> limitation on the build daemons, which only consider the first package in a
> list of alternatives.
>
> Kind Regards,
>
> Bas

But there are no alternatives.  The current policy says it must be
dependent on one *and* the other.  That is, that it should have
something like this line:

Depends: default-jre, java6-runtime

I may be reading the policy wrong, or missing the bigger picture on
how this interact.

Best Regards,
Carnë



Re: Why dependency on both default-jre and java-runtime

2017-08-24 Thread Bas Couwenberg

On 2017-08-24 16:15, Carnë Draug wrote:

Thank you for the answer but I still don't understand.  I get how the
use of virtual packages for java-runtime allows one to choose
OpenJDK or Oracle JDK.  What I don't understand is the default-jre
*and* java-runtime.  Actually, I don't understand the default-jre
at all if one also needs to specify a minimum java version via
java-runtime.


The first package in a list of alternatives must a be real package due 
to limitation on the build daemons, which only consider the first 
package in a list of alternatives.


Kind Regards,

Bas



Re: Why dependency on both default-jre and java-runtime

2017-08-24 Thread Carnë Draug
On 23 August 2017 at 21:43, Thorsten Glaser  wrote:
> On Wed, 23 Aug 2017, Carnë Draug wrote:
>
>> However, java-runtime packages are virtual packages provided by
>> default-jre so I don't understand why.  Could anyone clarify?
>
> They are also provided by openjdk-*-jre, so you can, for example,
> install a package depending on java6-runtime on wheezy (pre-LTS)
> whose default-jre pulled in openjdk-6-jre but run it with
> openjdk-7-jre instead of that. Or even openjdk-8-jre backported
> yourself.
>
> That’s extremely useful. It’s best to have at most *one* JRE
> on any given Debian system, after all. Experience speaking.
>
> bye,
> //mirabilos

Hi

Thank you for the answer but I still don't understand.  I get how the
use of virtual packages for java-runtime allows one to choose
OpenJDK or Oracle JDK.  What I don't understand is the default-jre
*and* java-runtime.  Actually, I don't understand the default-jre
at all if one also needs to specify a minimum java version via
java-runtime.

Using your example, installing a package on wheezy that is dependent
on default-jre and java6-runtime allows one to use openjdk-7-jre
instead (I guess wheezy default-jre was once openjdk-6-jre).

However, being dependent on java6-runtime alone would suffice since
openjdk-7-jre would also provide it.  The extra dependency on
default-jre would only add openjdk-6-runtime which was not actually
necessary.

I'm probably missing something important on how the java alternatives
and jre's work.  I'm packaging a java program now (been doing some
work on the imagej package for debian-med), I would like to understand
this properly.

Thank you
Carnë



Re: Why dependency on both default-jre and java-runtime

2017-08-23 Thread Thorsten Glaser
On Wed, 23 Aug 2017, Carnë Draug wrote:

> However, java-runtime packages are virtual packages provided by
> default-jre so I don't understand why.  Could anyone clarify?

They are also provided by openjdk-*-jre, so you can, for example,
install a package depending on java6-runtime on wheezy (pre-LTS)
whose default-jre pulled in openjdk-6-jre but run it with
openjdk-7-jre instead of that. Or even openjdk-8-jre backported
yourself.

That’s extremely useful. It’s best to have at most *one* JRE
on any given Debian system, after all. Experience speaking.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

**Besuchen Sie uns auf der dmexco!**
13. und 14. September 2017, Messe Köln,** Halle 7.1, Stand E042**
Digital Marketing Exposition & Conference
[www.tarent.de/dmexco](http://www.tarent.de/dmexco)

Wir empfehlen unseren Vortrag
"Wettbewerbsanalyse im Handel: Preisvergleich online und offline"
am 13. September, 18:00 Uhr im Speaker's Forum / Broadway

*

**Visit us at dmexco!**
September 13th and 14th, 2017, Messe Köln,** Hall 7.1, Booth E042**
Digital Marketing Exposition & Conference
[www.tarent.de/dmexco](http://www.tarent.de/dmexco)

We recommend our presentation
"Competitor analysis in retail: price comparison online and offline"
on September 13th, at 6 pm at the Speaker's Corner / Broadway

*



Re: Why dependency on both default-jre and java-runtime

2017-08-23 Thread Markus Koschany
Hi,

Am 23.08.2017 um 20:11 schrieb Carnë Draug:
> Hi
> 
> I was going through the pkg-java policy and found this [1]:
> 
> Programs must depend on the needed runtime environment
> (default-jre or default-jre-headless if need a GUI or not, and
> java-runtime or java-runtime-headless as provided by
> alternative Java environments).
> 
> However, java-runtime packages are virtual packages provided by
> default-jre so I don't understand why.  Could anyone clarify?

This policy requirement is to ensure that users can opt to choose the
Oracle JDK instead of OpenJDK. Oracle JDK is one of the "alternative
Java environments". The package "java-package" will produce suitable
debs which also provide java-runtime-{headless}.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature


Why dependency on both default-jre and java-runtime

2017-08-23 Thread Carnë Draug
Hi

I was going through the pkg-java policy and found this [1]:

Programs must depend on the needed runtime environment
(default-jre or default-jre-headless if need a GUI or not, and
java-runtime or java-runtime-headless as provided by
alternative Java environments).

However, java-runtime packages are virtual packages provided by
default-jre so I don't understand why.  Could anyone clarify?

Thank you
Carnë

[1] https://www.debian.org/doc/packaging-manuals/java-policy/x105.html