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.
