Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
View Poll Results: Do you have this same problem by any chance?
I've been wondering this since I first started using Linux, and, I'm sure I always will. I don't understand how all the packages fit together in installations. Let me explain further.
I was looking around on the FreeBSD website (this post doesn't have anything to do with FreeBSD) and I looked up Enlightenment on the ported applications page. It said it needed these things:
Now. I will try to explain my dilemma. Take for instance, tiff-3.5.7. I'll presume that means libtiff. Are there NO OTHER tiff libraries out there at all? None. On the off chance that there is another one, why can't it use those other tiff libraries. A tiff is a tiff.
Ok. That point seemed lame possibly, but, I'll try to explain further. Linux, being open-source, is a community of sharing. This is all well and good, but, it brings up a *possibly* confusing topic for me. How do I know that the files I need are only distributed in one certain package?? For example:
I need joebob.o to run program A. Well, since everyone in the Linux community seemingly has access to everything, what if that joebob.o is packaged in 11 different packages? All of the people that it was packaged by might think that they have the most useful package, but, it just confuses ME! How do I know where to get the official package that it wants. The files that it really wants, not something similar. How do I know I have the right version.
Or, my other dillema.
If program A wants the package called package1, because it has joebob.o in it, how does it know that I installed package1, and not package2, both which contain joebob.o.
I don't get how packages are aware of other packages existence!
I'm going to hope that these ramblings were clear, or else I'll have to come back and ramble some more. And that won't be pretty.
*this was added 10 minutes later* I was browsing the boards, and a good example of what I was talking about came up. Look at it here.
Well, let me explain it to you, as I understand it, with comparison to a MS Windows environment, in which everything is @#$@ed up most of the time, due to this very issue.
In the open source world as I've seen it, all libraries that are required are distributed in seperate packages as you stated. Your example, app X wants Tiff Lib A, well why can't it use Tiff Lib B instead of A, even though they are both Tiff Libraries.
By distributing all libraries by themselves and requiring you to download these libraries, it therefor keeps all versions and weird distributions off your system, that might otherwise cause problems. That really doesn't make sense, so let me try to explain further.
In the Windows world, you have DLL A, which is distributed with Windows. You want to install Application Z, which has a modified version of DLL A, and overwrites the one you currently had during installation.
You then install Application X, which required DLL A, but now you have a new DLL A, which was replaced by Application Z, causing Application X to page fault and crash your system. If this DLL would have been distributed separately as it's own program and App X and Z would have made this a prerequsite prior to their installation, they both would have worked instead of bombing your system.
With Linux, these libraries are distributed by themselves in order to help eliviate this problem. I'm sure there are many other reasons as well, but this is the most obvious to me right now, given your question.
As far as App Y requiring App G because it has Library X ... I'm not aware of this kind of situation EVER happening in Linux. If App Y requires App G to be installed, it is for the purpose of whatever App G services. For example, the WVDIAL app requires the PPPD app in order to serve it's purpose. I have never had to install a second app because it contained some library. I've always had to install these independant of the program.
"the existence of perfectly functional wheels in UNIX has never prevented their reinvention"... -
that's a quote from kernighan or one of those guys from the 60's who invented the whole unix thing... don't remember who exactly. either way, it embodies a certain spirit of unix, which linux has more than surpassed it in.
to be short, there is NO one solution to any problem. not tiffs, not jpegs, not mpg's... go count the number of mp3 en/decoders out there. any programmer can use any library/ other program they want... but then the high-level program they built is dependant on that lower level program.
programs are not flexible creatures. if they need tiff-3.5.7 to function, then replacing libtiff with tiff-0.19 will NOT work.
Well, I delved deeper into my problem, and I realize my ACTUAL concern. It's that fact that there is no constant source to get the things you may need. Like the post above, with that poor sap you couldnt find that file. He had to search EVERYWHERE and still didnt find it. It just seems intolerable that programs dont come with what they need to run.
Quick Question relating to the topic at hand - When I download Opera, there is always a Statically linked, and a Dynamically linked. I'm 90% sure that statically linked means the libraries that it needs to run are included, and are installed with it, in it's directory, like the DLL A of above. And dynamic uses libraries in /lib, or some other place.
Am I right? This might just make some more sense. (see's the goodness of the BSD Port Collection..)
The one thing no one else has really covered is package dependencies...
Compiling from source, automake and the instructions in the configure script search through every directory in your path. To see what's in your path, look at .bash_profile. Usually they'll find everything program-wise in /bin, /usr/bin, /usr/local/bin, or /usr/X11/bin.
Libraries meanwhile are usually in /lib /usr/lib /usr/local/lib or /usr/X11/lib ... notice a patern yet?
Usually programs are not as finicky about what they require to compile. They usually won't need joe1.2, but instead any version of joe after 1.1
Also, Slackware packages, although useful, are the least common pre-compiled-clumps running around out there with all the RedHaters and Mandy users the RPM has the Slack Pack and even the .deb beat on users by probably 30 to 1.
You might want to try doing an LFS... that can teach you a whole lot more than months of hacking Slack.
i think i see your concerns. seems to me you are thinking since it is open source, and say 100 different programs require the 1 lib(dependacy), and it comes packaged with those apps, what is to keep people from throwing a trojan or backdoor in that lib. this comes from the open source community being one big family, and not wanting to screw anyone over, but that doesnt stop the few malicious hackers/users from creating that lib. the best thing to do when you need a dependacy for a file, is to go to the source(the developer) and get that file.
as far as the static, versus dynamically linked programs go, lfs gave me the best definition/differences from the 2. here is the excert from the lfs book.
When making (compiling) a program, rather than having to rewrite all the functions for dealing with the kernel, hardware, files, etc. everytime you write a new program, all these basic functions are instead kept in libraries. glibc, which you install later, is one of these major libraries, which contain code for all the basic functions programs use, like opening files, printing information on the screen, and getting feedback from the user. When the program is compiled, these libraries of code are linked together with the new program, so that it can use any of the functions that the library has.
However, these libraries can be very large (for example, libc.a from can often be around 2.5MB), so you may not want a seperate copy of each library attached to the program. Just imagine if you had a simple command like ls with an extra 2.5MB attached to it! Instead of making the library an actual part of the program, or Statically Linked, the library is kept a seperate file, which is loaded only when the program needs it. This is what we call Dynamically Linked, as the library is loaded and unloaded dynamically, as the program needs it.
So now we have a 1kb file and a 2.5MB file, but we still haven't saved any space (except maybe RAM until the library is needed). The REAL advantage to dynamically linked libraries is that we only need one copy of the library. If ls and rmboth use the same library, then we don't need two copies of the library, as they can both get the code from the same file. Even when in memory, both programs share the same code, rather than loading duplicates into memory. So not only are we saving hard disk space, but also precious RAM.
To understand this dependency thing, you need to understand the rpm package manager. Try 'man rpm'.
When you install packages, rpm builds a database of packages and files and so on. When you add another, it checks the dependencies in that package against the database it has created. So if you need, say, libtiff, for a package, then this has to be in the database, which it will if another package has installed it.
The quality of the dependency list relies on the package author getting it right. Try reading MaximumRPM from Red Hat if you want to know about building rpm packages.
Try 'rpm -q --requires (package)' or 'rpm -q --provides (package)' to see some of these lists in action.
As an aside, if you try to delete a package, rpm will check the database to see if another package needs it, then stop you. Much better than any windows app.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.