Re: The evils of /usr/share/java/repository
On Sun, Sep 16, 2001 at 02:05:20PM -0700, Per Bothner wrote:
> Andrew Pimlott wrote:
>
> >On Thu, Sep 13, 2001 at 08:55:04PM +1000, jeff wrote:
> >
> >>But I'll spare you that ranting; let's just say I think it's a
> >>horrifically bad idea to have a free-for-all in one's classpath.
> >>
> >
> >I tend to agree, though I should point out that the opposite view
> >has support. For example, Per Bothner said in a previous thread,
> >
> > In Java we have a global namespace, so the user/developer should
> > not have to specify classpaths etc by default.
> >
> > (http://lists.debian.org/debian-java/2001/debian-java-200104/msg00014.html)
> >
> >I mention this because Per qualifies as something of an authority
> >IMO but has not not appeared on this list lately.
> >
> I still feel strongly the sentiment you quoted. A distribution should
> be a collection
> of software that works smoothly together. While it may support multiple
> versions of
> packages, we set it up so that users *and* developers by default get the
> "current stable"
> version of all packages, that they work together, and that developers
> can use installed
You have a good point here. And as I can see this is what have
existed before. The lib-xt-java, lib-dom-java lib-xslp-java (and more)
are the current stable version. Well they are that because they are not
developed anymore. The problem is when a better alternative arises.
Like xerces that extends and implements all lib-dom-java things and more.
They are source compatible but not binary compatible. :( So which one to
have as default?
So is it a bug (suddenly) to have lib-dom-java in the repository because
there are a better version?
> "devel" packages without *having* to specify "give me version X.X of
> package P and
> version Y.Y of package Q". We assume that current stable and consistent
> versions
> of header files and libraries are in /usr/include and /usr/lib, and only
> in exceptional
> cases should the user have to add extra -I or _L flags - and certainly
> not when
> using the*installed* current default version of a package. Why should
> Java be
> different? A Java developer should not be asked to specify classpaths for
Java is different because it is too new and because the software (out there)
have not been stable enough. But there is a need for it so people will use
it anyway and that is the fact that we have to face.
> packages that have been properly installed, unless they *want* (or need)
> to specify
> a particular version. The conclusion is that when a Java package is
> installed the
> default classpath (for all installed supported Java implementations)
> should somehow
> be changed to include the installed package (unless the package is a
> "compatibility"
> or otherwise "non-default" version).
As I can see we have to make up a rule when a package are allowed
to be in the repository, if we should keep it.
1* The package have to be a stable version.
2* The package have to fully support some specific standard.
(Like servlet-2.2)
3* The package have to have a good namespace so that later (incompatible)
implementation does not conflict with this namespace.
This is the basic requirements that I can come up with. And of course this
should be the goal (except for the 2* maybe) for all packages. But we are
not (maybe sometimes) upstream developers so it might not be as easy to fix.
But to me it is better to have a system to automaticly include the standard
jar-files in a more flexible way then extracting them to a repository.
That is my point of view but you have rized a good point and that is
that we should have the goal to have a consistent java system.
Regards,
// Ola
--
--------------------- Ola Lundqvist ---------------------------
/ opal@debian.org Björnkärrsgatan 5 A.11 \
| opal@lysator.liu.se 584 36 LINKÖPING |
| +46 (0)13-17 69 83 +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 /
---------------------------------------------------------------
Reply to: