[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Summary of the id?as.

On Wed, Sep 19, 2001 at 11:03:50AM +1000, Jeff Turner wrote:
> On Tue, Sep 18, 2001 at 02:44:00PM +0200, Ola Lundqvist wrote:
> > To discuss:
> > -----------
> > 
> > * Should we allow library packages to provide different versions?
> >   Like libxalan2 that provides both xalan1 and xalan2 jars.
> > * Should there be a script that automaticly fixes the symbolic
> >   links in the /usr/share/java directory.
> > * Must programs also place their files in /usr/share/java.
> I'd have thought program-specific jars are by definition, not shared,
> and therefore do not belong on /usr/share?

/usr/share is for files that can be shared among machines (of different
architectures), not necessarily for files that can be shared among

I can imagine some packagers preferring to put .jar files that only they
care about into /usr/share/<package> rather than /usr/share/java,
though, to keep the namespace clean.

> > Default classpath:
> > ------------------
> > 
> > * This discusses the default classpath, except the classpath that
> >   are needed by the jvm. Should there be any such thing?
> Or rather, *can* any such thing exist without:
>  - breaking non-packaged programs which assume a clean classpath.
>  - upsetting a lot of developers who like to make a clean-classpath
>    assumption. I think most Apache coders fall into this category,
>    because most (all?) Apache projects ignore the classpath, and use an
>    Ant properties file to find jars. Perhaps other Apache people <waves
>    to Marcus Crafter> can confirm/deny this.

I think there's got to be some kind of default classpath, even if it can
be overridden, otherwise programs without a startup script require the
user to set an environment variable before they can be used (see Debian
policy 10.9: "A program must not depend on environment variables to get
reasonable defaults").

Colin Watson                                  [cjwatson@flatline.org.uk]

Reply to: