More strange F9 dependencies

[Gordon Messmer]

Beartooth wrote:
> [root at 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.