Re: Packaging questions

[Ola Lundqvist]

Hi

On Tue, Nov 14, 2006 at 05:03:22PM +0100, Arnaud Vandyck wrote:
> On 11/13/06, Benjamin Mesing <[EMAIL PROTECTED]> wrote:
> >[Why is it, that nobody honors my request for CC?]
> >
> >Thanks for the answers. I would definitely recommend to create a
> >java5.0-compiler and java5.0-runtime package.
> 
> I don't like the idea because the development environment is not just
> about a compiler; also, there are plans for java6 and java7: how many
> virtual package will we have in Debian?
> 
> As Java should be compatible with old compiled code, we should drop
> old jdk's/jre's when new are out. Maybe keep two version at the same
> time for a moment and then, drop it.
> 
> The evolution of GNU Classpath will soon permit we move every package
> to java5. We'll have to refactory the way we create the java virtual
> packages with the Sun's jdk/jre in main in April or so.

I fully agree. And if we create virtual packages they should be
something that confirm to some kind of standard.

Regards,

// Ola

> Cheers,
> 
> -- 
> Arnaud Vandyck
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact 
> [EMAIL PROTECTED]
> 
> 

-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Annebergsslingan 37  \
|  [EMAIL PROTECTED] 654 65 KARLSTAD  |
|  +46 (0)54-10 14 30  +46 (0)70-332 1551   |
|  http://www.opal.dhs.org UIN/icq: 4912500 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Packaging questions

[Arnaud Vandyck]

On 11/13/06, Benjamin Mesing <[EMAIL PROTECTED]> wrote:

[Why is it, that nobody honors my request for CC?]

Thanks for the answers. I would definitely recommend to create a
java5.0-compiler and java5.0-runtime package.


I don't like the idea because the development environment is not just
about a compiler; also, there are plans for java6 and java7: how many
virtual package will we have in Debian?

As Java should be compatible with old compiled code, we should drop
old jdk's/jre's when new are out. Maybe keep two version at the same
time for a moment and then, drop it.

The evolution of GNU Classpath will soon permit we move every package
to java5. We'll have to refactory the way we create the java virtual
packages with the Sun's jdk/jre in main in April or so.

Cheers,

--
Arnaud Vandyck


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Packaging questions

[Benjamin Mesing]

[Why is it, that nobody honors my request for CC?]

Thanks for the answers. I would definitely recommend to create a
java5.0-compiler and java5.0-runtime package.

I will use the dependency on sun-java5 for now and put it in contrib.

Regards Ben




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Packaging questions

[Andrew Haley]

Marcus Better writes:
 > Benjamin Mesing wrote:
 > > However it requires Java 5.0 and I haven't found any information if
 > > there is a 5.0 compatible free java compiler available.
 > 
 > I don't think so, but check GCJ upstream. It's not just the compiler, but
 > also the class library that needs to support some new features, such as
 > generics.

gcj is now feature complete, but unstable.  It's basically alpha
quality.  I'll probably check in a merge with mainline gcj some time
this week.  I'mo not sure when it'll be ready for release, but it'll
be a good while yet.

Andrew.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Packaging questions

[Marcus Better]

Benjamin Mesing wrote:
> However it requires Java 5.0 and I haven't found any information if
> there is a 5.0 compatible free java compiler available.

I don't think so, but check GCJ upstream. It's not just the compiler, but
also the class library that needs to support some new features, such as
generics.

What Java 5.0 features does it use? Some programs can easily be back-ported
(there are some tools that help this process). Otherwise you have to build
with Sun-JDK and the package will go in contrib.

> Also, how would I specify a dependency on Java 5.0?

For the build-deps you should depend on the specific JDK, i.e.,
sun-java5-jdk. Check http://pkg-java.alioth.debian.org/ for some tips on
Java packaging.

Not sure if we have virtual packages for Java 5.0 runtimes yet. Should we
use "java5.0-runtime"? Until then your package should Depend on
sun-java5-jre and java-common.

> Looking at the sun-j2sdk1.5

That package is obsolete. Use sun-java5-jdk from non-free instead.

Marcus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Packaging questions

[Benjamin Mesing]

[please CC I am not subscribed]

Hello,

I intent to package UMLet [1,2] which is a neat little UML editor.
However it requires Java 5.0 and I haven't found any information if
there is a 5.0 compatible free java compiler available. Also, how would
I specify a dependency on Java 5.0?
Looking at the sun-j2sdk1.5 it provides (among others) j2sdk1.5 and
j2re1.5. However this seems non-standard to me (e.g. jikes-sablevm
provides only java-compiler).

Any help would be appreciated.

Regards,

Ben

[1] http://www.umlet.com/
[2] ITP #398093


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Java packaging questions (And looking for a sponser)

[Idan Sofer]

I've began packaging gcjlib ant task into a .deb:
http://spindazzle.org/gcjlib/

I've already filled an ITP:
http://bugs.debian.org/310962

And initial package, which passes the lintian tests is available on the
mentors repository:
http://mentors.debian.net/debian/pool/main/g/gcjlib-anttasks/

First, since i'm not a DD, I'm looking for someone to sponser the
package(and I assume here will be a good place to look for one:-))

Regardless, I have a couple of questions specific to packaging java
.debs, which are not addressed by the java policy

* Naming convention

The package is neither stand alone program, nor a library, rather, it is
an extension for ant. I've followed the convention defined by the
"aspectj-anttasks" package, but since it's the only example I could
find, i'm uncertain if that is the correct practice

* Dependencies

I've noticed "aspectj-anttasks" depends only on ant - excluding
java-virtual-machine and java-runtime as required by the policy. this
seemed to make sense, as ant already depends on them - I've followed
this practice, but i'm still not sure if it's the "right way".

* Max heap size

While package works correctly under the latest Kaffe(thus allowing to be
put on main), however, it requires increasing the maximal heap size - I
do not see how /usr/bin/ant can pass parameters to the VM from the
command line(thus providing a reasonable workaround) - one has to modify
/usr/bin/ant manually, which is unaccepable.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: java packaging questions

[Matthew Sherborne]

What about saving it as a lib and creating a sim-link to it named
/usr/bin/saxon also?

:)
- Original Message -
From: "Mark Johnson" <[EMAIL PROTECTED]>
To: 
Sent: Tuesday, June 26, 2001 1:53 AM
Subject: java packaging questions


> Hi All,
>
> I package some of the DocBook XML stuff and want to package some java
> xslt processing tools as well, but I'm not too clear on a few policy
> points. Any help/suggestions would be much appreciated. Here goes:
>
> 1. Package naming, libraries vs. programs, etc.
>
>I recently uploaded an xslt processor package, lib-saxon-java,
>which follows the policy naming conventions in java-common 0.7:
>
>  "Packages written in Java are separated in two categories:
>   programs and libraries. Programs are intended to be run by
>   end-users. Libraries are intended to help programs to run and to
>   be used by developers. Both must depend on
>   java-virtual-machine."
>
>   [...]
>
>  "There is no naming rules for programs, they are ordinary
>   programs, from the user point of view. Libraries packages must
>   be named lib-XXX-java."
>
>But saxon can be viewed as either a library or a program (if
>wrapper scripts are included.) Although I did follow the naming
>policy for libraries, many other packages do not. Is lib-saxon-java
>an appropriate name?
>
>Furthermore, since I'd like to make it easy for users to do XML
>processing (esp DocBook), I'd like to package some type of
>wrappers. Should I do this separately?  Or should I simply provide
>example scripts with lib-saxon-java for use with gcj and
>/usr/bin/java - type executables?
>
>I have similar questions for other packages I'd like to upload. The
>arbortext catalog classes (and related extensions) that provide
>catalog support for saxon and XT are an example. I could package
>the base classes as "lib-arbortext-java", the saxon extensions as
>"lib-saxcat-java" and make two more packages "xt-catalog" and
>"saxon-catalog" that provide wrapper scripts. Would such a
>combination be appropriate?
>
>
> 2. Package building: Is it necessary to recompile upstream jar files?
>
>  I hope not. :-)
>
>
> 3. Dependencies: The java-common policy states
>
>  "Both [libraries and programs] must depend on
>   java-virtual-machine."
>
>But many current java packages do not have this
>dependency. Suggestions?
>
>
>
> Many thanks,
> Mark
>
> --
> _
> Mark Johnson
> Duke Physics<[EMAIL PROTECTED]>
> Debian SGML <[EMAIL PROTECTED]>
> Home Page:  <http://dulug.duke.edu/~mark/>
> GPG fp: 50DF A22D 5119 3485 E9E4  89B2 BCBC B2C8 2BE2 FE81
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]
>
>

Re: java packaging questions

[Matthew Sherborne]

What about saving it as a lib and creating a sim-link to it named
/usr/bin/saxon also?

:)
- Original Message -
From: "Mark Johnson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 26, 2001 1:53 AM
Subject: java packaging questions


> Hi All,
>
> I package some of the DocBook XML stuff and want to package some java
> xslt processing tools as well, but I'm not too clear on a few policy
> points. Any help/suggestions would be much appreciated. Here goes:
>
> 1. Package naming, libraries vs. programs, etc.
>
>I recently uploaded an xslt processor package, lib-saxon-java,
>which follows the policy naming conventions in java-common 0.7:
>
>  "Packages written in Java are separated in two categories:
>   programs and libraries. Programs are intended to be run by
>   end-users. Libraries are intended to help programs to run and to
>   be used by developers. Both must depend on
>   java-virtual-machine."
>
>   [...]
>
>  "There is no naming rules for programs, they are ordinary
>   programs, from the user point of view. Libraries packages must
>   be named lib-XXX-java."
>
>But saxon can be viewed as either a library or a program (if
>wrapper scripts are included.) Although I did follow the naming
>policy for libraries, many other packages do not. Is lib-saxon-java
>an appropriate name?
>
>Furthermore, since I'd like to make it easy for users to do XML
>processing (esp DocBook), I'd like to package some type of
>wrappers. Should I do this separately?  Or should I simply provide
>example scripts with lib-saxon-java for use with gcj and
>/usr/bin/java - type executables?
>
>I have similar questions for other packages I'd like to upload. The
>arbortext catalog classes (and related extensions) that provide
>catalog support for saxon and XT are an example. I could package
>the base classes as "lib-arbortext-java", the saxon extensions as
>"lib-saxcat-java" and make two more packages "xt-catalog" and
>"saxon-catalog" that provide wrapper scripts. Would such a
>combination be appropriate?
>
>
> 2. Package building: Is it necessary to recompile upstream jar files?
>
>  I hope not. :-)
>
>
> 3. Dependencies: The java-common policy states
>
>  "Both [libraries and programs] must depend on
>   java-virtual-machine."
>
>But many current java packages do not have this
>dependency. Suggestions?
>
>
>
> Many thanks,
> Mark
>
> --
> _
> Mark Johnson
> Duke Physics<[EMAIL PROTECTED]>
> Debian SGML <[EMAIL PROTECTED]>
> Home Page:  <http://dulug.duke.edu/~mark/>
> GPG fp: 50DF A22D 5119 3485 E9E4  89B2 BCBC B2C8 2BE2 FE81
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]
>
>



--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: java packaging questions

[Egon Willighagen]

On Monday 25 June 2001 15:53, Mark Johnson wrote:
> Hi All,
>
> I package some of the DocBook XML stuff and want to package some java
> xslt processing tools as well, but I'm not too clear on a few policy
> points. Any help/suggestions would be much appreciated. Here goes:
>
> 1. Package naming, libraries vs. programs, etc.
>
>But saxon can be viewed as either a library or a program (if
>wrapper scripts are included.) Although I did follow the naming
>policy for libraries, many other packages do not. Is lib-saxon-java
>an appropriate name?

I think it is. Java 'binaries' must also contain a executable in /usr/bin.
You might want to put this in a package called saxon-java which depends
on lib-saxon-java...

>Furthermore, since I'd like to make it easy for users to do XML
>processing (esp DocBook), I'd like to package some type of
>wrappers. Should I do this separately?  Or should I simply provide
>example scripts with lib-saxon-java for use with gcj and
>/usr/bin/java - type executables?

see above: new package with out of the box working executable...

>I have similar questions for other packages I'd like to upload. The
>arbortext catalog classes (and related extensions) that provide
>catalog support for saxon and XT are an example. I could package
>the base classes as "lib-arbortext-java", the saxon extensions as
>"lib-saxcat-java" and make two more packages "xt-catalog" and
>"saxon-catalog" that provide wrapper scripts. Would such a
>combination be appropriate?

That sounds reasonable...

> 2. Package building: Is it necessary to recompile upstream jar files?
>
>  I hope not. :-)

Yes, i believe it is...

> 3. Dependencies: The java-common policy states
>
>  "Both [libraries and programs] must depend on
>   java-virtual-machine."
>
>But many current java packages do not have this
>dependency. Suggestions?

issue i bug report?

BTW, what is the status of the Java policy? Does the Debian policy state
that Java software must fullfil Java policy? Or is it just work in progres?

Egon

Re: java packaging questions

[Tollef Fog Heen]

* Mark Johnson 

|I have similar questions for other packages I'd like to upload. The
|arbortext catalog classes (and related extensions) that provide
|catalog support for saxon and XT are an example. I could package
|the base classes as "lib-arbortext-java", the saxon extensions as
|"lib-saxcat-java" and make two more packages "xt-catalog" and
|"saxon-catalog" that provide wrapper scripts. Would such a
|combination be appropriate?

I'd say that having this solution is quite ok.  Adding suggests or
recommends to lib-{arbortext,saxcat}-java might be appropriate as
well.

| 2. Package building: Is it necessary to recompile upstream jar files?
| 
|  I hope not. :-) 

Shouldn't be, but you can if you want to.

| 3. Dependencies: The java-common policy states
| 
|  "Both [libraries and programs] must depend on
|   java-virtual-machine."
| 
|But many current java packages do not have this
|dependency. Suggestions?

file bugs?

-- 

Tollef Fog Heen
You Can't Win

Re: java packaging questions

[Egon Willighagen]

On Monday 25 June 2001 15:53, Mark Johnson wrote:
> Hi All,
>
> I package some of the DocBook XML stuff and want to package some java
> xslt processing tools as well, but I'm not too clear on a few policy
> points. Any help/suggestions would be much appreciated. Here goes:
>
> 1. Package naming, libraries vs. programs, etc.
>
>But saxon can be viewed as either a library or a program (if
>wrapper scripts are included.) Although I did follow the naming
>policy for libraries, many other packages do not. Is lib-saxon-java
>an appropriate name?

I think it is. Java 'binaries' must also contain a executable in /usr/bin.
You might want to put this in a package called saxon-java which depends
on lib-saxon-java...

>Furthermore, since I'd like to make it easy for users to do XML
>processing (esp DocBook), I'd like to package some type of
>wrappers. Should I do this separately?  Or should I simply provide
>example scripts with lib-saxon-java for use with gcj and
>/usr/bin/java - type executables?

see above: new package with out of the box working executable...

>I have similar questions for other packages I'd like to upload. The
>arbortext catalog classes (and related extensions) that provide
>catalog support for saxon and XT are an example. I could package
>the base classes as "lib-arbortext-java", the saxon extensions as
>"lib-saxcat-java" and make two more packages "xt-catalog" and
>"saxon-catalog" that provide wrapper scripts. Would such a
>combination be appropriate?

That sounds reasonable...

> 2. Package building: Is it necessary to recompile upstream jar files?
>
>  I hope not. :-)

Yes, i believe it is...

> 3. Dependencies: The java-common policy states
>
>  "Both [libraries and programs] must depend on
>   java-virtual-machine."
>
>But many current java packages do not have this
>dependency. Suggestions?

issue i bug report?

BTW, what is the status of the Java policy? Does the Debian policy state
that Java software must fullfil Java policy? Or is it just work in progres?

Egon


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: java packaging questions

[Tollef Fog Heen]

* Mark Johnson 

|I have similar questions for other packages I'd like to upload. The
|arbortext catalog classes (and related extensions) that provide
|catalog support for saxon and XT are an example. I could package
|the base classes as "lib-arbortext-java", the saxon extensions as
|"lib-saxcat-java" and make two more packages "xt-catalog" and
|"saxon-catalog" that provide wrapper scripts. Would such a
|combination be appropriate?

I'd say that having this solution is quite ok.  Adding suggests or
recommends to lib-{arbortext,saxcat}-java might be appropriate as
well.

| 2. Package building: Is it necessary to recompile upstream jar files?
| 
|  I hope not. :-) 

Shouldn't be, but you can if you want to.

| 3. Dependencies: The java-common policy states
| 
|  "Both [libraries and programs] must depend on
|   java-virtual-machine."
| 
|But many current java packages do not have this
|dependency. Suggestions?

file bugs?

-- 

Tollef Fog Heen
You Can't Win


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

java packaging questions

[Mark Johnson]

Hi All,

I package some of the DocBook XML stuff and want to package some java
xslt processing tools as well, but I'm not too clear on a few policy
points. Any help/suggestions would be much appreciated. Here goes:

1. Package naming, libraries vs. programs, etc.

   I recently uploaded an xslt processor package, lib-saxon-java,
   which follows the policy naming conventions in java-common 0.7:

 "Packages written in Java are separated in two categories:
  programs and libraries. Programs are intended to be run by
  end-users. Libraries are intended to help programs to run and to
  be used by developers. Both must depend on
  java-virtual-machine."

  [...]

 "There is no naming rules for programs, they are ordinary
  programs, from the user point of view. Libraries packages must
  be named lib-XXX-java."

   But saxon can be viewed as either a library or a program (if
   wrapper scripts are included.) Although I did follow the naming
   policy for libraries, many other packages do not. Is lib-saxon-java
   an appropriate name?

   Furthermore, since I'd like to make it easy for users to do XML
   processing (esp DocBook), I'd like to package some type of
   wrappers. Should I do this separately?  Or should I simply provide
   example scripts with lib-saxon-java for use with gcj and
   /usr/bin/java - type executables?

   I have similar questions for other packages I'd like to upload. The
   arbortext catalog classes (and related extensions) that provide
   catalog support for saxon and XT are an example. I could package
   the base classes as "lib-arbortext-java", the saxon extensions as
   "lib-saxcat-java" and make two more packages "xt-catalog" and
   "saxon-catalog" that provide wrapper scripts. Would such a
   combination be appropriate?


2. Package building: Is it necessary to recompile upstream jar files?

 I hope not. :-) 


3. Dependencies: The java-common policy states

 "Both [libraries and programs] must depend on
  java-virtual-machine."

   But many current java packages do not have this
   dependency. Suggestions?



Many thanks,
Mark

-- 
_
Mark Johnson
Duke Physics<[EMAIL PROTECTED]>
Debian SGML <[EMAIL PROTECTED]>
Home Page:  
GPG fp: 50DF A22D 5119 3485 E9E4  89B2 BCBC B2C8 2BE2 FE81

java packaging questions

[Mark Johnson]

Hi All,

I package some of the DocBook XML stuff and want to package some java
xslt processing tools as well, but I'm not too clear on a few policy
points. Any help/suggestions would be much appreciated. Here goes:

1. Package naming, libraries vs. programs, etc.

   I recently uploaded an xslt processor package, lib-saxon-java,
   which follows the policy naming conventions in java-common 0.7:

 "Packages written in Java are separated in two categories:
  programs and libraries. Programs are intended to be run by
  end-users. Libraries are intended to help programs to run and to
  be used by developers. Both must depend on
  java-virtual-machine."

  [...]

 "There is no naming rules for programs, they are ordinary
  programs, from the user point of view. Libraries packages must
  be named lib-XXX-java."

   But saxon can be viewed as either a library or a program (if
   wrapper scripts are included.) Although I did follow the naming
   policy for libraries, many other packages do not. Is lib-saxon-java
   an appropriate name?

   Furthermore, since I'd like to make it easy for users to do XML
   processing (esp DocBook), I'd like to package some type of
   wrappers. Should I do this separately?  Or should I simply provide
   example scripts with lib-saxon-java for use with gcj and
   /usr/bin/java - type executables?

   I have similar questions for other packages I'd like to upload. The
   arbortext catalog classes (and related extensions) that provide
   catalog support for saxon and XT are an example. I could package
   the base classes as "lib-arbortext-java", the saxon extensions as
   "lib-saxcat-java" and make two more packages "xt-catalog" and
   "saxon-catalog" that provide wrapper scripts. Would such a
   combination be appropriate?


2. Package building: Is it necessary to recompile upstream jar files?

 I hope not. :-) 


3. Dependencies: The java-common policy states

 "Both [libraries and programs] must depend on
  java-virtual-machine."

   But many current java packages do not have this
   dependency. Suggestions?



Many thanks,
Mark

-- 
_
Mark Johnson
Duke Physics<[EMAIL PROTECTED]>
Debian SGML <[EMAIL PROTECTED]>
Home Page:  
GPG fp: 50DF A22D 5119 3485 E9E4  89B2 BCBC B2C8 2BE2 FE81


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]