RE: [SLE] Microsoft Vs. Linux Desktop Battle Heats Up
Actually, I agree with the thought of using a separate directory for the libraries, but it should only be necessary when the need library cannot be found on the system that you are loading on. You are probably correct in the cause of dll-hell, however if the libraries were more standardized it might help as well. Jonathan
-----Original Message----- From: Nick LeRoy [mailto:nleroy@cs.wisc.edu] Sent: Tuesday, June 10, 2003 1:21 PM To: suse-linux-e@suse.com Subject: Re: [SLE] Microsoft Vs. Linux Desktop Battle Heats Up
If the package would include the necessary libraries to install and run, rather than being dependentant on what the distro may already come with, should resolve this issue. For the most part just about every package I have come across I could compile and execute on Mandrake, SuSE, Red Hat, Debian, and *BSD. There is only the matter of porting the
On Tuesday 10 June 2003 1:03 pm, Jonathan Shilling wrote: libraries.
Jonathan
Sorry, but I ardently disagree here. This is what all the Windoze apps do, and is IMHO what's been known to cause the DLL-hell that anybody whose ever used windoze has battled too many times.
Now, I suppose I might relax my position _if_ it could install these libs in a non-shared (ie app specific) location. Instead of installing a different libfoo.so in /usr/lib, package bar installed in, say, /opt/bar, and installed /opt/bar/lib/libfoo.so and /opt/bar/bin/bar is a shell script that sets LD_LIBRARY_PATH before starting the _real_ /opt/bar/bin/bar.bin. Even then, however, I'd say this should only be done _when neccessary_.
-Nick
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
On Tue, Jun 10, 2003 at 01:40:21PM -0500, Jonathan Shilling wrote:
Actually, I agree with the thought of using a separate directory for the libraries, but it should only be necessary when the need library cannot be found on the system that you are loading on.
This is what OSX apps can do. If there is anything app-specific, it goes into the app directory. And to OSX, an "application" isn't an executable, but actually that directory, Application.app. I know that my copy of Applixware 5.0 does this: when installing, it checks for correct versions of libraries. If they are not there, I am given the option of opdating my system or of installing those libraries for use only with Applixware. Because of this, I have a software package that I originally put on RedHat in 2000 and just last month installed on SuSE 8.2 and it works still.
You are probably correct in the cause of dll-hell, however if the libraries were more standardized it might help as well.
I don't understand what you mean. libgtk is built from the same source whether it's on RHL, Mandrake, Debian, or SuSE. I don't pretend to know everything about linux, though, so perhaps I will learn something from your troubles. -Michael
On Tuesday 10 June 2003 1:53 pm, Michael George wrote:
On Tue, Jun 10, 2003 at 01:40:21PM -0500, Jonathan Shilling wrote:
Actually, I agree with the thought of using a separate directory for the libraries, but it should only be necessary when the need library cannot be found on the system that you are loading on.
This is what OSX apps can do. If there is anything app-specific, it goes into the app directory. And to OSX, an "application" isn't an executable, but actually that directory, Application.app.
I know that my copy of Applixware 5.0 does this: when installing, it checks for correct versions of libraries. If they are not there, I am given the option of opdating my system or of installing those libraries for use only with Applixware. Because of this, I have a software package that I originally put on RedHat in 2000 and just last month installed on SuSE 8.2 and it works still.
You are probably correct in the cause of dll-hell, however if the libraries were more standardized it might help as well.
I don't understand what you mean. libgtk is built from the same source whether it's on RHL, Mandrake, Debian, or SuSE. I don't pretend to know everything about linux, though, so perhaps I will learn something from your troubles.
After reflecting on it a bit more, I want more than just this, too... Let's say that I'm installing application "foo" (I just love that name), and it needs lib "bar" which is currently not installed. I Boldly Assert(tm) that the "foo" installer should: 1. Consult RPM or whatever package manager is installed, and tell it "I'm looking for libbar.so version 1.2.3 . Please install it if you can". 1a. RPM then checks its database of things that came with the distro, and says, "yep I have it, and I just installed it for you" (during which time it'll have prompted the user to insert CD 3, etc.). 1b. RPM checks it's database and says "I don't know about libbar.so". 2. The application installer then installs libbar.so on it's own in /opt/bar... Question: Does RPM store the CD directory some place? I don't know. Thoughts? Flames? -Nick
Nick LeRoy (nleroy@cs.wisc.edu) wrote:
1. Consult RPM or whatever package manager is installed, and tell it "I'm looking for libbar.so version 1.2.3 . Please install it if you can".
And what about ability that RPM or whatever package recognize that the library is installed from the compiled sources? It's, imho, one of the very frustrating things connected with the binary distros and/or RPM package manager-oriented ones. Sincerely, Gour -- Gour gour@mail.inet.hr Registered Linux User #278493
Op dinsdag 10 juni 2003 21:39, schreef Gour:
And what about ability that RPM or whatever package recognize that the library is installed from the compiled sources?
It's, imho, one of the very frustrating things connected with the binary distros and/or RPM package manager-oriented ones.
What about using "checkinstall" to install your own compiled sources. This will keep the rpmdb and filesystem contents consistent. -- Richard Bos Without a home the journey is endless
On Tue, Jun 10, 2003 at 10:02:34PM +0200, Richard Bos wrote:
And what about ability that RPM or whatever package recognize that the library is installed from the compiled sources?
It's, imho, one of the very frustrating things connected with the binary distros and/or RPM package manager-oriented ones.
What about using "checkinstall" to install your own compiled sources. This will keep the rpmdb and filesystem contents consistent.
I agree. If you know how to compile, then you should be able to do checkinstall. Besides, while I'm quite comfortable with building from source, I haven't had to do that for *any* library since switching to RHL some 8 years ago. -Michael
Richard Bos (radoeka@xs4all.nl) wrote:
What about using "checkinstall" to install your own compiled sources. This will keep the rpmdb and filesystem contents consistent.
Oops.. Thank you for the info. I just learnt something new since I was not aware of it. Sincerely, Gour -- Gour gour@mail.inet.hr Registered Linux User #278493
On Tue, Jun 10, 2003 at 02:03:37PM -0500, Nick LeRoy wrote:
Let's say that I'm installing application "foo" (I just love that name), and it needs lib "bar" which is currently not installed.
I Boldly Assert(tm) that the "foo" installer should:
1. Consult RPM or whatever package manager is installed, and tell it "I'm looking for libbar.so version 1.2.3 . Please install it if you can".
1a. RPM then checks its database of things that came with the distro, and says, "yep I have it, and I just installed it for you" (during which time it'll have prompted the user to insert CD 3, etc.). 1b. RPM checks it's database and says "I don't know about libbar.so".
2. The application installer then installs libbar.so on it's own in /opt/bar...
Question: Does RPM store the CD directory some place? I don't know.
I don't know how SuSE does it, but they come close to this. I just keep the DVD in the drive and whenever I need something I start YaST, find it, check it, it checks dependencies, click "finish" and off it goes. I've not found it that difficult. If one is using esoteric software that has a very niche market, then there might be some esoteric libs that you have to seek out.
On Tuesday 10 June 2003 1:40 pm, Jonathan Shilling wrote:
Actually, I agree with the thought of using a separate directory for the libraries, but it should only be necessary when the need library cannot be found on the system that you are loading on. You are probably correct in the cause of dll-hell, however if the libraries were more standardized it might help as well. Jonathan
Yes, I know that, but I was referring to installing random application "foo"
which YaST has no idea about. You know, the type that come with their own
propriety installer that does what it wants....
And Richard Bos
This is exactly what the Advanced Package Tool (apt) does. More about apt at http://linux01.gwdg.de/apt4rpm. The gui for apt is synaptic.
Looks cool, like it does a lot of things that I've been doing by hand for too many years. I guess the real issue is that each application typically comes with their own fancy installer, and doesn't take advantage of these capabilities. How do we get them to use the standard tools. I guess there's still an issue with .deb vs. .rpm, etc. Sigh. <rant> We _need_ a standard set of these tools that _all applications_ can depend on existing, no matter what distro you're installing on. Then, the application developer merely ships with a single "package" file set, hands it to an installer that does the work on it, installs what it needs to from the CDs, internet, ether, application packages, etc., in an intelligent way, stores it in some database, I guess, and, well, holds the user's hand along the way, creates links for KDE, etc. While we probably have individual tools that can do this (apt maybe? YAST?), they're not univerally available AFIK, and that's the problem. </rant> -Nick
On Tue, Jun 10, 2003 at 02:56:19PM -0500, Nick LeRoy wrote:
Yes, I know that, but I was referring to installing random application "foo" which YaST has no idea about. You know, the type that come with their own propriety installer that does what it wants....
If that's the case, blame the app, not the distro. This is like me buying an aftermarket kit to hop up my 440 Hemi and expecting Chrysler to have an automated way to install it. If I get a 3rd part X, then the 3rd part should have directions for installing X and help on their web site. -Michael
participants (5)
-
Gour -
Jonathan Shilling -
Michael George -
Nick LeRoy -
Richard Bos