[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: More strange F9 dependencies



Beartooth wrote:
[root Hbsk2 ~]# yum remove bluez-*
...
Removing:
bluez-libs i386 3.36-1.fc9 installed 126 k bluez-utils-cups i386 3.36-1.fc9 installed 40 k

I feel like I should point out that all of this fuss is over 166k. That disk space costs about $.02.

Some make mud seem clear. I don't understand, despite googling, what gvfs is or does.

It's the Glib virtual file system. Rather than use the standard libc routines for file access, applications which use glib can use its IO routines and will be able to access data from various sources in addition to plain files. For instance, an application can open an "ftp://"; file using the same functions as a local file on disk.

But what of nautilus? It would be fine for bluez to depend on it; but why should it depend on bluez??

Because nautilus depends on gvfs, like virtually all of GNOME does, for file IO. According to the information that rpm has, removing bluez will break gvfs, which would break nautilus.

Is someone going to tell me that pango uses bluez, with or without hardware? And then sneer down his nose that I'm welcome to write new code??

Are you bringing this up in order to pursue a vendetta from a previous conversation? You've got to relax, man.

Maybe it'd help to understand how "ld.so" works. Simplified: When you start a dynamic executable, it gets loaded into memory. ld.so examines it for a list of libraries that it was linked to when it was compiled. It searches the directories configured in /etc/ld.so.conf and loads those into memory too. It then examines the dynamic executable for a list of functions that are used, and searched for those in the libraries. When found, it adjusts some pointers to functions and starts running the dynamic executable. The process of loading and searching for libraries is recursive; if a library is dynamically linked then ld.so has to process it in mostly the same way. If any library or function can't be found, an error is printed and the application fails to start.

The point of illustrating that is that your idea of "use" isn't the same as ld.so's. The loader can't determine whether or not you will attempt to transfer files by bluetooth. Its job is simply to make sure that the libraries exist, and that they contain the correct symbols. An application always "uses" the libraries that it linked with.

	What ever became of linux being tailorable??

GNU/Linux systems are as tailorable as they ever were *because you have the source*. The ability to tailor a GNU system has never meant that you could tear out binary components that you thought looked funny without causing the system to fail. It means that if you are knowledgeable, you can modify the system to do what you want it to -- and it always has.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]