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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.