> No, I'm saying that OpenSource Motif *will* be going through lots of
> gyrations in the future, and these gyrations may cause instabilities in
> the JDK.
> But, if the JDK uses the Motif version it was compiled against, it will
> work 'consistently.
> Unlike X (which rarely changes), I suspect the Motif stuff to change
IT seems to me that this might not be much of a problem. Have a "last
stable motif" port/package. The JDK guys can choose when to move it to a
new version, and should do so when they see a version that doen't cause
problems for the JDK. Don't give this port/package the normal motif
library names, but sim-link it to those names. Compile the JDK against
the special lib names, not the normal motif names. Now, have a "bleeding
edge" motif that can be installed. it installs into the normal motif
look what this does for the user:
1. If they'd rather be stable anyways, they just install the last-good
version. all is well - both the jdk and their other apps see an
2. If they need bleeding-edge, they can install it. JDK will still work.
Yes, they have two motif versions, but they need both versions, so this is
3. If they start out last-good, and move to bleeding edge, everything
works out just fine.
4. If a bleeding-edge user updates their last-good motif, it doesn't screw
things up since last-good can't sim-link over the real libs. Just the JDK
5. If a user doesn't use the jdk, they can install bleeding-edge and it
works for all non-JDK apps.
One usefull addon would be to have bleeding-edge re-create the last-good
sim-links when it is pkg_deleted if that's possible.
Just my $0.02
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message