Re: [Fwd: Re: [Dlc-discuss] [Fwd: Linux fragmentation and desktop standards]]

James Richard Tyrer <[email protected]>
Newsgroups gmane.comp.kde.cafe
Message-ID <[email protected]>
Aaron J. Seigo wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Thursday 10 April 2003 08:23, James Richard Tyrer wrote:
> 
>>	/usr/lib/mozilla/plugins/
>>
>>	/usr/mozilla/plugins/
>>
>>	/usr/local/mozilla/plugins/
>>
>>Nobody has explained to me why the first one is better or more logical.
> 
> 
> here's my guess: because the plugins (plugins/) are dynamic components (lib/) 
> of a user application (/usr) named mozilla (mozilla/)
> 
> the other locations don't match that profile as well... the unix fs system is 
> supposed to be layed out according to function (programs, libraries, 
> configurations, etc) and scope (system admin, users, things specific to the 
> local system, etc)

Unfortunately, this logic leads to:

/usr/lib/qt-3.1/bin/qtconfig

A path with both 'lib' and 'bin' in it????

NO, I didn't make that up:

http://rpmfind.net//linux/RPM/redhat/9/i386/qt-3.1.1-6.i386.html

My theory:

/usr/qt-3.1/bin/qtconfig

/usr/local/qt-3.1/bin/qtconfig

> the big problem is, as Dennis noted earlier, is that there isn't 
> standardization (yet) across Linux OS vendors or even individual applications 
> (as Maks pointed out Mozilla spews files into different dirs from version to 
> version). 

You miss the point.  Mozilla doesn't do that, the distro does.  Mozilla always installs in the 
same default directory: "/usr/local/mozilla"

so we end up not only with tons of files located in the same
> directories but those files are not distributed consistently across systems 
> ... if we could achieve consistency, then we'd be a long ways towards 
> understandability.

Unfortunately the worst offender: RedHat seems to think that they are achieving consistency 
through their slicing and dicing of packages.

--
JRT


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.