FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 05-03-2008, 06:01 AM
Les Mikesell
 
Default Multilib Middle-Ground

Colin Walters wrote:



The point is that for years fedora has had a scheme of package

requirements and no standard-compliant JVM that provided them. And it has a
strange symlinked path scheme that needs to be fixed when installing a
standard JVM.


I find the symlink/alternatives structure *so much* better than having
to munge the PATH and JAVA_HOME environment variables that I don't
understand why you're complaining about it.


One complaint is that it subverts something obviously intended to be a
per-process choice into a per-machine configuration. What do you do if
you, or different users, need to simultaneously run different versions
of JVM's - something that seems likely during any transition where you'd
want to keep the old version running until you have thoroughly tested
its replacement? But, given that the alternatives structure is there
even with its limitations, the real issue is that there have been long
periods of time when you could not find a java-sun-compat package
documented to work with the current fedora version and that's not
something you want to set up by hand.



You are confusing 2 issues. By standard-compliant, I mean the language
spec which does exist and as far as I know, nothing fedora has ever shipped,
meets.


I couldn't find the status of OpenJDK 6 is with respect to the TCK in
a brief search, but if Fedora's shipped package didn't pass I think it
would be regarded as an important bug.


And you'll just ignore the entire prior history of fedora?

--
Les Mikesell
lesmikesell@gmail.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-03-2008, 08:06 AM
Kevin Kofler
 
Default Multilib Middle-Ground

Les Mikesell <lesmikesell <at> gmail.com> writes:
> And you'll just ignore the entire prior history of fedora?

You mean the prior history of _Java_!

Fedora merely shipped the only available option which was Free Software. Blame
Sun Microsystems for not having made their implementation Free Software right
from the start.

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-03-2008, 10:36 AM
"SL Baur"
 
Default Multilib Middle-Ground

On 5/2/08, Kevin Kofler <kevin.kofler@chello.at> wrote:
> Les Mikesell <lesmikesell <at> gmail.com> writes:
>
> > Can't you just always provide at least 2 versioned libraries? One
> > essentially equivalent to the latest released RHEL or Centos version(s)
> > and the other whatever flavor is current? And unless apps need
> > something new, build them against the stable version.
>
>
> Fedora is about CURRENT technology. They will ALWAYS prefer the CURRENT version
> of the libraries if it is at all possible. Why should Fedora build against an
> old one? You are using the wrong distribution.

There are some libraries that are never worth extinction. Berkeley DB is one
of them. It's a data file format and special. I can see how the ancient 1.8.x
wouldn't be loved here, but it's still *stupid* dropping it even as an option.
*STUPID*.

> We can't ship unmaintained old versions forever.

No, but dropping stuff before they break or while there are users[1]
is Just Plain
Stupid.

-sb (Yes, I suppose I do have an axe to grind).

[1] Especially Enterprise users in the case of RHEL.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-03-2008, 11:32 AM
Patrice Dumas
 
Default Multilib Middle-Ground

On Sat, May 03, 2008 at 03:36:35AM -0700, SL Baur wrote:
>
> > We can't ship unmaintained old versions forever.
>
> No, but dropping stuff before they break or while there are users[1]
> is Just Plain
> Stupid.

You can submit compat packages to fedora for the old berkeley db
versions. If you do so, it may be wise to ask here and also contact the
maintainer of the current version before, to see if there is
disagreement.

--
Pat

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-03-2008, 03:41 PM
"Colin Walters"
 
Default Multilib Middle-Ground

On Sat, May 3, 2008 at 2:01 AM, Les Mikesell <lesmikesell@gmail.com> wrote:
>
> One complaint is that it subverts something obviously intended to be a
> per-process choice into a per-machine configuration. What do you do if you,
> or different users, need to simultaneously run different versions of JVM's -
> something that seems likely during any transition where you'd want to keep
> the old version running until you have thoroughly tested its replacement?

You set PATH and JAVA_HOME, just like you did before. What the
alternatives system gives you is a sane way to make one the default,
which you need to have it integrated with other components of the
operating system.

> But, given that the alternatives structure is there even with its
> limitations, the real issue is that there have been long periods of time
> when you could not find a java-sun-compat package documented to work with
> the current fedora version and that's not something you want to set up by
> hand.

I don't see a lot of value in continuing to discuss this, given that
in the near future all supported Fedora releases (8 and 9) will have
built-in very complete Free Java implementations.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-03-2008, 04:20 PM
Les Mikesell
 
Default Multilib Middle-Ground

Kevin Kofler wrote:

Les Mikesell <lesmikesell <at> gmail.com> writes:

And you'll just ignore the entire prior history of fedora?


You mean the prior history of _Java_!


If you mean the reason it - and much of the other currently open source
software exists at all, you shouldn't ignore that either. As much as I
like open source and freely available code, I recognize that much would
never have existed if it were not for original proprietary work - and
that we are all better off as a result of everyone's participation with
the proprietary version.


Fedora merely shipped the only available option which was Free Software. Blame
Sun Microsystems for not having made their implementation Free Software right
from the start.


I blame fedora for not maintaining a relationship with japackage.org
until their users no longer need what they provide. In fact, I don't
see any reason any java code needs to be specialized for a distribution
or included in its own repository. Why not just make fedora work with
an external repo for java that works across distributions/versions and
avoid the issue entirely instead of shipping something that isn't quite
java? Even when a real java can be included, what is the point of
having specialized distro/version packages of the apps that don't need
specialization?


--
Les Mikesell
lesmikesell@gmail.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-03-2008, 04:41 PM
Rahul Sundaram
 
Default Multilib Middle-Ground

Les Mikesell wrote:

In fact, I don't
see any reason any java code needs to be specialized for a distribution
or included in its own repository. Why not just make fedora work with
an external repo for java that works across distributions/versions and
avoid the issue entirely instead of shipping something that isn't quite
java? Even when a real java can be included, what is the point of
having specialized distro/version packages of the apps that don't need
specialization?


There is no "specialization" usually necessary for including software in
the repository. Fedora avoids specialization by being close to upstream
usually. Relying on a external repository for Java would mean that we
can't include any Java programs within Fedora. Parts of Openoffice.org,
Eclipse and dozens of programs were introduced into the repository
because of the work that went into GCJ, classpath etc and even OpenJDK
has benefited from that now.


Rahul


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-03-2008, 06:00 PM
Nicolas Mailhot
 
Default Multilib Middle-Ground

Le samedi 03 mai 2008 à 01:01 -0500, Les Mikesell a écrit :

> One complaint is that it subverts something obviously intended to be a
> per-process choice into a per-machine configuration. What do you do if
> you, or different users, need to simultaneously run different versions
> of JVM's

You write the bits needed to support switching jvms at the user level
via environment variables, and you submit them to jpp for merge in
jpackage-utils. This has been explicitely marked as a welcome
enhancement for five years

http://www.jpackage.org/cgi-bin/viewvc.cgi/rpms/free/jpackage-utils/doc/jpackage-1.5-policy.xhtml?revision=1.2&root=jpackage&pathrev=MA IN#id2493509

I guess none of the people who need it want to write a line of shell
script.

--
Nicolas Mailhot
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-03-2008, 06:04 PM
Nicolas Mailhot
 
Default Multilib Middle-Ground

Le samedi 03 mai 2008 à 22:11 +0530, Rahul Sundaram a écrit :

> There is no "specialization" usually necessary for including software in
> the repository. Fedora avoids specialization by being close to upstream
> usually.

I'm afraid a lot of the java upstreams have a long way to go before
FLOSS OSes can be close to them. After drumming for years "don't think
about the OS, java will hide the OS layer for you" SUN managed to create
thousands of developers that actively want nothing to do with the OS
problems.

--
Nicolas Mailhot
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-03-2008, 06:14 PM
Nicolas Mailhot
 
Default Multilib Middle-Ground

Le vendredi 02 mai 2008 Ã* 22:31 +0000, Kevin Kofler a écrit :

> JPackage has no guideline which forbids Free packages to have dependencies
> (RPM "Requires:") on non-Free ones, and there are some which do, even where it
> is possible to build the package without that dependency. Fedora had to patch
> out those dependencies when importing those packages. I don't remember the
> exact affected packages, but I do remember there were some packages which had
> non-Free dependencies removed as part of the import into Fedora.

Well the right way would have been to provide a replacement for the
proprietary crap, not to remove user functionality. If you can put a
FLOSS JVM under most jpp packages, that's because the deps are meant to
be replaced by FLOSS stuff (and when they can't because the FLOSS
project decided it would be smart not to copy the proprietary blob
layout, the deps are changed at request).

Many jpackage rpms were created before FLOSS replacements existed. I'm
sorry we lacked the cristal ball to predict what would or would not have
a FLOSS alternatives later. We knew most of it would get alternatives –
otherwise it would have been a lot less work just to hardcode a
particular JVM everywhere like everyone else was doing (and still is
BTW).

--
Nicolas Mailhot
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 09:18 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org