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. 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. 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. There are all sorts of packaging options used by other distributions and like rpm, they all have their strengths and weaknesses. 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. The thing to consider is that packaging is rarely a problem for open source, GPL compatible software because the distribution packagers can always adjust, tweak and shape the packaging. On the restricted license packages, that necessarily is the burden of the owners of the software and that is where the problem lies. Craig
