[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Cross posting per request



From: Glenn Bily <gvb@elentari.cs.wcu.edu>
> 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

How about /usr/lib/i386-elf and /usr/lib/i386-aout?
That lets you support multiple architectures more easily.
I think this is more desirable from an architecture standpoint
than an executable format standpoint - a.out is quickly waning,
but supporting hetrogenous architectures is a continuing problem.

Please contact Dan Quinlan <quinlan@bucknell.edu> about joining
the FHS group - they are the ones who will make this decision.
Please get the current draft of the FHS standard from Dan (it's
long) and become familiar with it before you join the discussion
on their mailing list.

> If /usr/local is really for local configuration then it shouldn't be in
> /usr.

Yes. It should probably be a symlink to somewhere else out of the box
on a freshly-installed Debian system. The installation scripts can do
that. Please submit a bug report on the "boot-floppies" package about
this so I won't forget it. The info on how to use the bug system is
on our web page www.debian.org .

> On a debian system I am looking at has a /usr/local/lib/emacs which I
> consider to be stranded.

Please check that the _current_ Emacs package still does this.
Debian packages aren't supposed to touch /usr/local at all, but perhaps
some of them create directories there to give the user a hint that programs
will look in there.

> /local/etc would be configuration files typically found /etc.

/etc is by definition local - however I have done it exactly as you describe
on my system (before upgrading with dpkg became so easy) in order to tell
what I had changed. I've actually thought about using a source control system
(like RCS) on /etc . "dpkg" doesn't currently know how to check control files
in and out of RCS - is this a good idea? Currently, it will leave a
"filename.dpkg-new" file around for you to hand-edit if you decline to
over-write a control file.

There should also be a dpkg flag to ask it if you have altered a control
file from the version in the package. Since it keeps the md5 checksum
around, that is possible.

> 3) Server and client installation distinctions. Possible avenue for easy 
> minimal setup of X clients.

Is this "select a preset list of packages depending on what I say
I want to use the system for"? We just put functionality in dpkg that
would make that easy to implement.

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

I'm not sure I understand the list of action items required for the above.
I think it's just a matter of choosing the right packages - something we
could definitely help the user with.

[discussion of several new startx features deleted]
> This would require a small adjustment in startx.

OK - go ahead and code it up, document it, and package it as an alternate
startx. Packaging documentation is now in the dpkg and debian-doc packages.
It's a lot easier now that there _is_ packaging documentation.
If you get satisfied Debian users of your package, that'll help you
convince XFree86 to adopt it.

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

/etc/X11/xinit only has one script on my system, and that's one I can see
reasons to edit. About 3 files in "xdm" could be elsewhere, but they are
small. You might want do discuss this with the "xdm" maintainer.

> The configuration programs for /etc/printcap and the user maintaince
> utilities from Redhat need to be lifted :)

Hm. Who is in charge of printer set-up?
I'd be happy to look at the user maintainance scripts from RedHat. Can
you mail them to me?

	Thanks

	Bruce



Reply to: