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

Aaron J. Seigo wrote:
> -----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. 
> 
Yes, that is my point -- that the distros don't do it correctly!
> 
>>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...
> 
I figure that we make an exception for Qt as what I think of as a major package and add an entry 
to the path and ld.so.conf file for it.  The alternative is to slice and dice it.
> 
>>My theory:
>>
>>/usr/qt-3.1/bin/qtconfig
>>
>>/usr/local/qt-3.1/bin/qtconfig
> 
> 
> or just /usr/bin/qtconfig
> 
That requires breaking up the package.
> 
>>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, 
> 
Clearly we can only add a path entry for major packages.  With executables, however, there are 
other alternatives.  The most obvious is a link and/or a startup script.  OTOH, if an executable 
is to be only accessed through a GUI, it doesn't need the directory added to the path.

> ld will have to search all over god's green earth for libraries......

LD.SO doesn't search for libraries.  The path is listed in: /etc/ld.so.conf and their locations 
are cached when you run: ldconfig.  However, most libraries that are used by other apps should 
be in one of the standard 'lib' directories to avoid the file getting too large.

> 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.
> 
There is nothing here about the package manager.  It is the HUMAN that chooses how to set up the 
package.  He could just as easily set it up the way that I think it should be done.

> 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.
> 
That is, as long as he can find a package of the application and/or library that he wants to 
install.  As Linux fragments, the problem becomes worse and worse as you reach the point that 
you MUST have a package for the specific distro or install from source which the slice and dice 
file arrangement makes very difficult.

> there is also a reason we have .desktop files and other such ease-of-use 
> systems.... they provide consistent shortcuts to system features...
>
But where do you put the "*.desktop" file?

> 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... 
> 
I don't advocate that.  What I advocate is that installing from a package should put the files 
in the exact same place (with the exception of: /usr/ vs. /usr/local/ -- we are stuck with that) 
as they would be if you installed yourself AND/OR that the correct place to install something is 
where the developer thinks it should be installed -- where it is installed if from source. 
There are a few questions here, but they could be easily ironed out.

--
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.