Re: How to install Java/Frefox in FC6 -

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux