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.
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
