Issue 79112 - file organization: too many library files (294) vs program files (99) in program directory
Summary: file organization: too many library files (294) vs program files (99) in prog...
Alias: None
Product: Installation
Classification: Application
Component: code (show other issues)
Version: OOo 2.2.1
Hardware: All Unix, all
: P4 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2007-07-02 20:02 UTC by cpmonger
Modified: 2013-02-07 21:58 UTC (History)
4 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---

openoffice-2.1.1--program--files.all.txt (28.23 KB, text/plain)
2007-07-02 20:03 UTC, cpmonger
no flags Details (20.73 KB, text/plain)
2007-07-02 20:04 UTC, cpmonger
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description cpmonger 2007-07-02 20:02:44 UTC



The ./program/ directory has 402 files, but only 99 are actual program related
files. It is suggested that the 294 library files be moved to their own
./program/lib sub-directory for organizational clarity.


The directory: ./program/ has 402 files (not including . and .. files)

Of those 402 total files, 9 are directory files.

Of the 393 remaining files, 294 are library files (ls -l *.so), including 19
links to other *.so files, totaling 73.13% of the directory files.

There are 99 remaining "program" files, only 33.67% of the directory files.


- This larger number of files is harder to read and understand.

- This directory is commonly linked to, or accessed by, to run actual program
files, yet library files (*.so) are never directly accessed, much less changed,
by users.

- In more sophisticated file system and program architecture arrangements,
libraries are not owned by a particular version, application, or vender, but 
are common with other vendor or open-system libraries. The application looks in
a hierarchy of numerous directories, with most cleanly named */lib/ . This 
avoids bloat from needless library duplication, yet permits library update
independent of application or version. (Yes, dependencies can be addressed.)

- Large file systems are incrementally slower for the OS file system to access.
Lengthy paths may have their own penalty, but I vaguely recall reading that UFS
file access time is the square of the number of files in the file directory.

- Cleanly segregating file types, when possible, is a "more organized" quality,
that may offer harder to define, second-order benefits.


- Create a ./program/lib directory, and move the ./*.so files to ./program/lib .

- This also requires various unknown changes in source code and make files.

- Also consider the directory name /library/ vs. /lib/ .

- Consider changes in relation to other general file organization and
installation location issues. File architecture has other OS and chip-set
implications. Application may at least extend to other Unix and OS-X (BSD).

Comment 1 cpmonger 2007-07-02 20:03:42 UTC
Created attachment 46449 [details]
Comment 2 cpmonger 2007-07-02 20:04:16 UTC
Created attachment 46450 [details]
Comment 3 Olaf Felka 2007-07-02 21:09:39 UTC
@ mh: Something for you to have a look at?
Comment 4 Martin Hollmichel 2007-07-03 10:03:42 UTC
reassign to Kay
Comment 5 kay.ramme 2007-07-06 14:56:17 UTC
->Ingo, Stephan: I think in general cpmonger is right ... mixing public and
private libraries and executables in the same directory is unfortunate. Do you
think it would be reasonable to "fix" this while we are working on the package
structure anyway?

Comment 6 Stephan Bergmann 2007-07-06 15:55:32 UTC
We should postpone this until later.  This is not important enough to burden
other, more important tasks with it.