Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

[Jan Schulz <jasc.usenet@gmx.de>]

Hallo Daniel,

* Daniel Bonniot wrote:
>javac can also be called during package building. Unless a specific 
>compiler (e.g. /usr/bin/jikes) is always used, but isn't that a burden 
>for users rebuilding packages?

What interface do you suggest? The discussion her pretty much showed,
that you can't rely on anything. This would mean:
* -classpath is probably save (-cp already not...)
* setting up rt.jar? in javac or in the calling script? The script
  doesn't know the location, so we would be better off with
  /usr/lib/java-dev-env, which would be relative easy to maintain.

Packagers, what do you need? The interface has to be used by YOU! :)
For package building, ant build.compiler should be enought,m but that
could be just my POV...

>>2.5. Classpath
>>/var/lib/java/ and place this jars in /usr/share/java. The JarDF must be
>Does this conform to the FHS?

I haven't looked. I just put it next to the package information of dpkg.

>http://www.pathname.com/fhs/2.2/fhs-5.8.html
> "This hierarchy [/var/lib] holds state information pertaining to an 
>application or the system. State information is data that programs 
>modify while they run, and that pertains to one specific host."
>What about /usr/share/java/<package name>.classpath ?

I don't like the idea about one dir for two very different things. If
/usr/share is better, it should probably be /usr/share/classpath or
/usr/share/classpath-data or so.

But IMO is this data 'state information' about the java programms,
which 'pertains to that one specific host'.

I will have a lookinto the FHS...

Thanks for this reply!

Jan
-- 
Jan Schulz                     jasc@gmx.net
     "Wer nicht fragt, bleibt dumm."