How to install Java/Frefox in FC6 -
Gene Heskett
gene.heskett at verizon.net
Tue Dec 19 18:28:59 UTC 2006
On Tuesday 19 December 2006 12:31, Craig White wrote:
>On Tue, 2006-12-19 at 11:58 -0500, Gene Heskett wrote:
>> On Tuesday 19 December 2006 07:42, Craig White wrote:
>> >On Mon, 2006-12-18 at 23:13 -0500, Ric Moore wrote:
>> >> On Mon, 2006-12-18 at 07:41 -0500, Bob Goodwin wrote:
>> >> > Tim wrote:
>> >> > > Today, when I tried the link from the Stanton-Finley site, Sun
>> >> > > didn't redirect me to the latest, but stayed at the release
>> >> > > number the link was intended for (1.5.x). It's now jre1.5.0_10
>> >> > > instead of jre1.5.0_8, so the paths in the examples to copy and
>> >> > > paste need correcting. That done, it worked, but the test page
>> >> > > wants to install a JRE plug in, even though it's apparently
>> >> > > working, and tells me I'm using an old version. The games
>> >> > > apparently work (not that *I* can play them).
>> >>
>> >> Mine did the very same thing until I closed my browser and started
>> >> it up again, then I passed with flying colors. I use the jre...bin
>> >> file instead of the rpm. As I've written, I stick it in /opt. Then
>> >> I chmod 755 the file (as root), execute it, it unpacks into it's
>> >> directory and then I link that directory to /opt/java. My links in
>> >> the mozilla / firefox and ~/.mozilla all point
>> >> to: /opt/java/plugin/i386/ns7/libjavaplugin_oji.so
>> >>
>> >> Next time I update I need only change one link. Nifty... works. I
>> >> just don't trust java and rpm in the same breath, not yet. Ric
>> >
>> >----
>> >with that kind of logic, why bother using an rpm distribution at all?
>> >
>> >Craig
>>
>> Because rpm needs help? A blasphemous thought now isn't it...
>>
>> rpm is being forked because the maintainers aren't responsive to such
>> issues. This may not be the ideal situation, but it sure beats doing
>> nothing.
>
>----
>not at all blasphemous - but not necessarily knowledgeable either.
Now you are pulling my trigger, grab your nomex underwear.
>rpm has served you since RHL 5 as I seem to recall but I also seem to
>recall that when building packages, you always opt for ./configure &&
>make && make install and I don't recall a single instance where you have
>made an effort to package anything yourself.
Entirely true. Why? Because I have NDI how to go about writing a spec
file, and the ones I've looked at seem somehow to be unrelated to the
package they came from. That's what checkinstall wants you to do when
you run it I believe, but all I've ever put in that is a comment or two
plus the packages name. Not right, but generally it keeps the rpm
database current as to what's installed.
>RPM is a rather rich environment that goes way beyond the
>simple ./configure && make && make install process including concepts
>such as where to put the installation, dependency checking, user
>creation/deletion, post-installation processing and more.
And its often the dependency checking that kills things. If I want to
install a newer version of cups or gutenprint, or maybe even ghostscript,
I damned sure don't need it ripping kde out by the roots just because
there's an erronious dependency on kprinter. But that's the choice I've
been given often enough that it doesn't bither me a bot to grab a tarball
and build it with the usual ./configure, make, make install routine when
at the end of the tarball install, it all works, which is a hell of a lot
more than I can say for the distro pckgs that came with FC2, and which to
my knowledge were never ever fixed.
The problem with FC2 and printing as FC2 shipped? Just hovering the mouse
(you didn't need to click, just pause over it for 100 milliseconds) over
the name of anything that involved printing in any way shape or form in
the kmenu would crash most of kde, requiring a reboot usually since a
ctl-alt-backspace and a new startx didn't usually fix it.
I rebuilt kde to kde-3.3.0 using konstruct, didn't fix it.
I updated gs, then rebuilt gs from a tarball, didn't fix it.
I ripped out foomatic, didn't fix it. Epson printers don't want it
anyway, screws up the color.
Updated cups using yum, didn't fix it, twice IIRC.
I built from a tarball, a alpha version of gutenprint, never looked back
it was that much better. But it didn't fix it either.
Built and installed a several versions newer cups from a tarball, bingo,
problem fixed. But AFAIK, the last cups I upgraded to was the last one
made available for FC2 via yum.
I came to the conclusion that this was a kde lovers punishment from TPTB.
I hate gnome with a passion, its far less intuitive to use and its damned
popups nagging me about being root were the last straw.
Yes, I'd build an rpm or several, but fedora in particular seems to want
to discourage that at all costs by hiding the src.rpm's from the
unwashed. Enabling the src repos doesn't result in my being able to see
them in yumex. Anybody know why or is this just more "company policy"?
I believe the last time I was able to successfully rebuild an rpm from its
src.rpm was back in RH7.3, I have never been able to get it to work
since. It seems my system always has something it doesn't need, or
doesn't have something it needs. A couple of times the rpm version has
been updated, but the src.rpm hadn't been adjusted to match, so the build
fails. Generally speaking, a ./configure sorts that stuff quite well.
And there needs to be someplace on the net a decent helpfile on writing
the spec file. Given the state of scripting languages today, there is no
excuse whatsoever for there not being a utility that can take the
tarballs config.status file once ./configure has been run, and extract
whats needed for the spec file from it. That would be the icing on the
cake for checkinstall IMNSHO.
>There are all sorts of packaging options used by other distributions and
>like rpm, they all have their strengths and weaknesses.
Yes, adept is ubuntu's current achilles heel. So I use synaptic on
kubuntu. It Just Works(TM).
Just like Fedoras shiny new smart package manager, which isn't. Yumex
hasn't goosed the moose yet (that I know of, but I have had to nuke the
__db00* files about 5 times so far in 2 months).
>That still doesn't help the fact that on an rpm based system, to
>do ./configure && make && make install on tarballs is a rather inelegant
>way of doing things since at the very least, the packages are not
>visible to the rpm package reporting processes themselves.
That (the invisibility to rpm's database) is the only disadvantage I'm
aware of. As far as the systems ability to use the program in question
is concerned, I've built far more stable code with ./configure, make,
make install as a general rule than I've been able to see from rpms
downloaded and installed as binary packages.
YMMV, but mine is pretty good in that department. That kde-3.3.0 I built
with konstruct never had 95% of the problems with kde-3.3.0 that went by
on the kde lists. The difference was so obvious I had to mention it,
several times.
Like I said, you pulled my trigger.. Now, how about some URL's I can
print and study so I can build an rpm without running into some missing
includes that aren't findable with yumex or some such?
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
More information about the fedora-list
mailing list