Cross posting per request
Folks,
These ideas are being posted here from net news per request.
Response is desired (even if it's not Debian priority)
1) Long awaited cleaning out of /usr/lib. In addition, categorizing
what is left into subdirectories.
A reasonable setup would be:
/usr/lib/elf -- elf shared libs
/usr/lib/aout -- a.out shared libs
/usr/lib/elf/static -- for static elf libs
/usr/lib/aout/static -- for static a.out libs
Other development packages could retain their own /usr/lib
subdirectories or more preferably build mini etc lib bin trees in
/usr/<package name>, /ap/<package name>, /usr/X11R6/<X package name>
directory. Such as:
/usr/lib/elf/SVGA
or
/usr/SVGA/lib
Things like /usr/lib/perl, /usr/lib/terminfo, etc. need to be moved back
to /usr or /ap were it makes more sense.
What are the advantages this?
If someone chooses not to install development type packages then their
lib directories are not cluttered with libraries that make the directory
long and unmanagable.
It great reduces confusion on the part of users and possibly developer
as to what libraries are where.
2) Figuring out whether /usr/local is really being used properly (which
in my reading of FSSTND it isn't)
If /usr/local is really for local configuration then it shouldn't be in
/usr. /usr would typically be read-only mounted to a server in the cases
where /usr/local would be used. You cannot mount on read-only
partitions.
The person maintaining the system would just end up making /usr/local a
symbolic link.
On a debian system I am looking at has a /usr/local/lib/emacs which I
consider to be stranded. The system is not a complete installation so
there is no telling what other things are placed in /usr/local.
A reasonable solution to this is to move /usr/local to /
I would create 2 directories in /local:
/local/bin
/local/etc
/local/bin would be placed in the path and would represent binaries that
would search before /usr/bin for binaries.
/local/etc would be configuration files typically found /etc. The person
maintaining the server would put symbolic links into /local/etc in /etc
if they need it to be a local configuration.
3) Server and client installation distinctions. Possible avenue for easy
minimal setup of X clients.
A person installing a Linux system should have the option of choosing
where they want the local machine to be the server or use a remote
server. There are still people out there who want to make use of machine
with 4 megs of ram. Running an X client on a 386 with 4 megs of ram and
a resonable video arrangement is not a bad thing and may be cost
effective in some environments.
4) Allowing controls of how many X sessions can be lauched would be
reasonable as well. X has the seemingly unknown feature of running
numerous client/servers. By adding :1, :2, etc as server arguments, you
can launch multiple X session possible on different servers from the
same console. This is extremely powerful to say the least.
It would be a bonus to be able to have a system admin control how many X
sessions are being launched at one console. This would require a small
adjustment in startx. In addition, it should not be required that the
user keep track of :1, :2, :3. This is another adjustment that would be
made in startx.
5) If a startup shell script for window managers should also be easy to
add.
I think that the user should have the possibility of specifying the
window manager at the startx prompt such as:
startx fvwm
startx openwin
startx fvwm-95
And have resonable assurances that it will work.
An additional bonus to this would be allowing root to setup a simple
table to map the names to various shell scripts that would start the
window managers. This would allow for practically all contingencies and
complexities in getting that window manager started. This would also
allow the package maintainer to move the main window manager binaries
out of the path and out of harms way.
6) The wisdom of put the contents of /etc/X11/xdm and /etc/X11/xinit
where they are needs to be re-evaluated.
Most of the files in these directories are shell scripts not
configuration files.
7) The configuration programs for /etc/printcap and the user maintaince
utilities from Redhat need to be lifted :)
Reply to: