Huh?

A lot of them in GNU/Linux; I think! (almost any distro)

I have installed a number of applications thru rpm. I have noticed some of the applications demand certain files and they are mostly files that are being shown a "DEPENDENCY"
or "libabcxyz.so.<no>" sort of the file

What are these exactly...???

They really disappoint me for using GNU/Linux and make me feel that it slightly becomes difficult for newbies....(I may go ahead and find out where the library file will b avaialbe) not many wud do that...
Rather, they wud not know how to go about...

The second question is ...can the pacakges have libraries embedded in them ...will that make the file size very huge ??? or will it make the package more bulky and redundant?

I sometimes assume that these are like the ones used with C programs....
(I remember )

Please answer my two questions....

The basic RPM tools reports dependencies in a way that other computer software can process. You probably want to be using software such as yum that takes care of which packages depend on which for you.

A .so file is a library of relocatable code, known as a shared-object library. That is, code that is loaded along with the program when the program is run.

Yes, you can link libraries with the executable code. This type of library is called a static-link library and has a filename ending in .a rather than .so. A shared library is used when the program is compiled.

There are a number of reasons why shared object libraries are preferred over static-linked ones. If two programs link to the same shared library then you only need to load the library into memory once. This saves memory and makes loading times much faster. Shared linking also makes things like application plug-ins easier, because you don't need the library to be around when the program is compiled.

There are advantages of static object libraries, too. You can optimise the library for your application and reduce the application's dependencies; you will sometimes see static binaries (binaries linked only with static libraries) for download on websites, especially if the library needed is obscure or an old version.

stdio.h is a header file, which includes prototypes for C's standard I/O library. All the standard C libraries are held in a file called libc.so or (less commonly) libc.a (at least on a GNU system). The C library is linked against your program while the stdio.h file is included in it as a stub to tell the program what's available in the C library.

Does this answer your questions?

Yes it does!

But there is one thing. A mechanism should be adopted such that library files will be embedded in an rpm and checked on installation of the whether the required library file is present or not and put the library file in its place in case it is missing.

I haven't used YUM much, (only once) where it downloaded certain things but I cud not find out how I automate the process for updating packages.

If only it were that easy! Many providers can produce different but compatible versions of the same library file, each of which would need to be embedded into the RPM, and you'd need a way of asking the user which version they would want.

Given that some commercial companies provide libraries (e.g. Intel provides a version of the C library), which can't be distributed seperately without paying for a licence fee each time, this would mean that the cost of each RPM file would be several thousand dollars, even for a single package, just for common libraries like libc. Not to mention that the file size would be hundreds of megabytes even for relatively simple programs, most of which would never be used.

Instead, packages have dependencies — almost every package requires /usr/lib/libc.so.6, but doesn't specify which package should provide it. GNU, Intel and various others can all provide their own RPM packages providing different versions of the libc.so.6 file, and RPM will be happy if any of these are installed, or will otherwise tell the package manager which to install. If you use RPM by hand, then you are the package manager and need to find out where to install it.

RPM is a very low-level tool for testing package dependencies, but it doesn't know how to fix them. Full-blown package managers like yum, yast, apt-get and so on all know about various RPM repositories from which they can download and/or install packages containing the required library files. But RPM can't know about this; each distribution implements its repositories differently and RPM is a general-purpose tool.