Re: [Fwd: Re: [Dlc-discuss] [Fwd: Linux fragmentation and desktop standards]]
"Aaron J. Seigo" <[email protected]>
| Newsgroups | gmane.comp.kde.cafe |
|---|---|
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 10 April 2003 11:58, James Richard Tyrer wrote: > Unfortunately, this logic leads to: > > /usr/lib/qt-3.1/bin/qtconfig > > A path with both 'lib' and 'bin' in it???? done 'correctly' qt's binaries and libraries would not be under the same /*/lib/* directory. > NO, I didn't make that up: > > http://rpmfind.net//linux/RPM/redhat/9/i386/qt-3.1.1-6.i386.html i never said that Red Hat or Qt were perfectly organized. a make install of Qt seems ends up with /usr/local/qt that has a bin, lib, plugin, templates and tools. bin and tools belong elsewhere, the lib/plugins belong in /usr/lib... > My theory: > > /usr/qt-3.1/bin/qtconfig > > /usr/local/qt-3.1/bin/qtconfig or just /usr/bin/qtconfig > Unfortunately the worst offender: RedHat seems to think that they are > achieving consistency through their slicing and dicing of packages. i don't know if they are the worst offender (or that they aren't), but what are the alternatives? /usr/<appname>/[bin|lib|etc] ? unless there is a way for binaries to register themselves w/the OS our $PATHS will be enormous, we'll have thousands of directories in our filesystems each with a few files in them, ld will have to search all over god's green earth for libraries...... there is a reason we have package managers ... they provide an interface to the filesystem for management of software and files. they aren't perfect yet, but they are a long ways there and are getting better. with decent package management, the average user should never need to understand the deep guts of the filesystem nor be bothered by it. meanwhile those who can manage it (and need to) along with the OS software will have a sane system to work with. there is also a reason we have .desktop files and other such ease-of-use systems.... they provide consistent shortcuts to system features... hierarchical filesystems are really great for certain situations, mostly those involving machine manipulation of systems. but most users should be given a more humane interface to interacting with their system than that. simply shifting things to /usr/<appname>/a/million/duplicated/directories isn't going to help many people IMO... there is one nice thing about having /usr/<appdir> type structures and that is that it's easier to control access to specific services by modifying permissions on individual application directories. that's mostly a server thing, however, and doesn't scale very well. - -- Aaron J. Seigo GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE: The 'K' is for 'kick ass' http://www.kde.org http://promo.kde.org/3.1/feature_guide.php -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+lmRL1rcusafx20MRAiJzAKClMneNyaiM8uZbN6OeTFddJHrr8ACZAXfN l3nPLxu4Aj1Ygkx+F6vti3U= =l3T3 -----END PGP SIGNATURE----- Kde-cafe mailing list - [email protected] http://ofb.biz/lists/listinfo.cgi/kde-cafe DISCLAIMER: The views expressed on this mailinglist are the personal opinions of the author and do not represent KDE or the author's employer.