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-02-2008, 10:20 PM
Les Mikesell
 
Default Multilib Middle-Ground

Kevin Kofler wrote:


I can say that OpenNMS won't currently work with a 1.6 version because
it's developers have said so.


Then surely you should blame OpenNMS for not supporting the latest version of
Java! Java is almost completely backwards-compatible, they have really no
excuses for still shipping something which doesn't work with the 1.5-year-old
latest version.


If it's so easy, perhaps you could check out a copy and offer them the
fixes.


By the way, have you really tried it? My experience is that stuff often just
works with IcedTea even if they claim to only support 1.5.


No, and it's not a particular problem as far as opennms itself goes
because their yummable repository includes a working JVM.


I don't understand what that has to do with making it difficult to
install a compliant version.


s/compliant/obsolete/


I suppose I can accept that as a description of some happy future time.

Quit talking about "standards compliant" when what you really want is ancient
legacy crap. The certified 1.6 implementation from Sun won't run those programs
any better than OpenJDK does.


Yes, I realize this will all get fixed in several more years. But our
internal stuff just went to 1.5 last year and it took non-trivial
changes so I don't expect everyone else to rush either.


conversations here I thought someone said the relationship was
deliberately broken with portions moved into fedora packages and the
rest ignored.


Are you trying to fault Fedora for including what they can include?


Yes, both for shipping a non-conforming implementation which harms
everyone involved, and for not shipping something to fix up the package
dependencies and alternatives symlinks peculiar to fedora when a user
installs a conforming implementation.


> Obviously
they won't include the non-Free crap which is on JPackage, nor stuff which
non-Free dependencies. Some of the incompatibilities in packaging are also due
to JPackage hardcoding dependencies on non-Free crap into Free packages which
aren't really necessary and which Fedora patches out.


I can't parse any of that. The jpackage nosrc packages don't include
any non-free bits - they just adjust things for fedora oddness.


--
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-02-2008, 10:23 PM
Les Mikesell
 
Default Multilib Middle-Ground

Kevin Kofler wrote:

Les Mikesell <lesmikesell <at> gmail.com> writes:
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.


Because no Free Software implements it completely (though OpenJDK is now
getting close). We can't ship what doesn't exist, and we aren't going to ship
proprietary stuff just because some "open source" packages have felt into the
Java Trap.


There never was a trap - just some lies about one.

--
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-02-2008, 10:24 PM
Kevin Kofler
 
Default Multilib Middle-Ground

Les Mikesell <lesmikesell <at> gmail.com> writes:
> There never was a trap - just some lies about one.

You clearly haven't understood what Free Software is about.

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-02-2008, 10:31 PM
Kevin Kofler
 
Default Multilib Middle-Ground

Les Mikesell <lesmikesell <at> gmail.com> writes:
> > By the way, have you really tried it?
> No

Then why not try it and complain about specific things which don't work, so
they can be fixed, either in OpenJDK/IcedTea if that's where the problem is, or
in OpenNMS if that's at fault?

> If it's so easy, perhaps you could check out a copy and offer them the
> fixes.

Are fixes even needed? What's broken exactly? You haven't even tried it...

> > Are you trying to fault Fedora for including what they can include?
>
> Yes, both for shipping a non-conforming implementation which harms
> everyone involved, and for not shipping something to fix up the package
> dependencies and alternatives symlinks peculiar to fedora when a user
> installs a conforming implementation.

Then you are a lunatic who really doesn't understand what Fedora is about.

Fedora will include whatever it can include without violating its guidelines.
If you want proprietary crap, you're at the wrong address. If you want Fedora
not to ship anything which has a proprietary equivalent, that would mean
shipping essentially nothing, after all there's a proprietary kernel, a
proprietary office suite etc. What you're asking for makes no sense.

> I can't parse any of that. The jpackage nosrc packages don't include
> any non-free bits - they just adjust things for fedora oddness.

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.

Kevin Kofler

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

Kevin Kofler 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.


Yes, I probably overstated the need for long term backwards
compatibility in fedora itself, although I still don't see why it is
impossible or undesirable. What I really want is a smooth transition
between those 'right' distibutions.... That is, assuming RHEL or Centos
as stable production environments, I want to be able to have a
development environment that doesn't take major work to keep running
things from the current production environment and by the time of the
next enterprise release also provides a smooth transition in that
direction. Sort of like the old days of using RH X.0 for
development/testing and by X.2 things were good to go.


I'd like to think of distributions as having some editorial control over
what they ship. If someone writes crap you don't have to publish it.
Or at least overlap old/new versions for a complete version run.


We can't ship unmaintained old versions forever. Are you going to maintain the
obsolete branches of things like GCC?


Isn't that already being done elsewhere? It is only unnecessary
fedora-specific incompatibilities that would keep you from using it.


--
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-02-2008, 10:45 PM
Mark Heslep
 
Default Multilib Middle-Ground

And another one for Ubuntu, another for Xandros, .... They have just
dumped other they used to support.


Kevin Kofler wrote:

Mark Heslep <mark <at> mitre.org> writes:


Plenty of other proprietary vendors have trouble:
http://www.codeweavers.com/account/downloads/



Trouble? They're able to ship a single package "for Red Hat, Mandriva, or
SuSE", which isn't even expected to work (you're supposed to build separate
packages for each), so this sounds like quite the opposite of "trouble" to me!


Kevin Kofler




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

Kevin Kofler wrote:

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

There never was a trap - just some lies about one.


You clearly haven't understood what Free Software is about.


It's not that I don't understand, I just don't agree that it is the only
way. Or that anything with an interface spec can ever be a trap.


--
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-02-2008, 10:54 PM
Les Mikesell
 
Default Multilib Middle-Ground

Patrice Dumas wrote:

On Fri, May 02, 2008 at 01:47:09PM -0800, Jeff Spaleta wrote:

On Fri, May 2, 2008 at 1:34 PM, Les Mikesell <lesmikesell@gmail.com> wrote:

I'd like to think of distributions as having some editorial control over
what they ship. If someone writes crap you don't have to publish it. Or at
least overlap old/new versions for a complete version run.

And a lot of the software in the open ecosystem is under heavy
development and do not need the backwards compatibility that you are
expressing a need for for your in-house code. If we used editoral


I don't think it is true. The truce is that many developers are
ignorant about ABI/API compatibility and don't even try to design API
sanely. Now this could be optimal in some sense, given that it is not a
very fun work, but the 'heavy development' is not the reason.


I don't think most people understand it until there is a change in their
own favorite tool or language that makes them go do all their work over
again or track down obscure bugs because of a library regression that
got by because nobody bothered to test the interfaces.


--
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, 03:49 AM
Rahul Sundaram
 
Default Multilib Middle-Ground

Les Mikesell wrote:

Kevin Kofler wrote:

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

There never was a trap - just some lies about one.


You clearly haven't understood what Free Software is about.


It's not that I don't understand, I just don't agree that it is the only
way. Or that anything with an interface spec can ever be a trap


Except that Sun Java itself has internal non-standard and undocumented
com.sun* interfaces and programs relying on it won't work on GCJ or
necessarily even between different revisions of the same JVM. Pretty
much ever major vendor using Java has their own VM that is atleast in
part incompatible with each other: Sun, Oracle, BEA, IBM ...


Rahul


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

On Fri, May 2, 2008 at 5:47 PM, Les Mikesell <lesmikesell@gmail.com> 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.

> 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.

--
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:47 PM.

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