Subject: Re: Cross posting per request

From: [email-masked] (Bruce Perens)
Date: Mon, 2 Sep 96 18:39 PDT

From: Glenn Bily <[email-masked]>
> 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 <[email-masked]> 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

---

From: Rob Browning <[email-masked]>
Date: 02 Sep 1996 21:11:31 -0500

> over-write a control file.

This sounds like a really nice idea, but I bet there could be nasty
logistical problems.

--
Rob

---

From: Glenn Bily <[email-masked]>
Date: Sun, 1 Sep 1996 22:18:18 -0400 (EDT)

Bruce,

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

If it is suppose to be empty...Then why should it be at all?

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

The difference between local configuration and global configuration is
vague. A good way to determine this would be: If I NFS mount /etc
read-only from a server on a client (of course you can't do this). What
would I find necessary to change to make the client work besides account
based stuff?
Off the top of my head...here are some pretty big candidates:

sendmail.cf
yp.conf
syslog.conf
securetty
printcap

Questionable:
hosts.*
shells
resolv.conf

If one wanted to give the installer a choice (wonderful!)  then shell
script could be lifted out of the kernel configuration utility. The type
of choice code that could be used has already been written.

> >> The wisdom of put the contents of /etc/X11/xdm and >/etc/X11/xinit
> >/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 fact you find need to edit this script suggest problems (to be
distinuish from /etc/X11/xdm/xdm-config which is a genuine configuration
file). One should be able to get away with only editing these scripts
once or twice in a blue moon. The rests of this work should be done in
~/.Xsession as a regular user.
It should be the perogative of any Unix system to keep users out of root
as much as possible.

---

From: Mark Eichin <[email-masked]>
Date: 02 Sep 1996 23:40:59 -0400

> Please check that the _current_ Emacs package still does this.

Current emacs does *create* the directory (ie. it is in the package
contents), as recommended by the debian packaging guidelines, as a
hint to the user that emacs will *look* there if there's anything in
it.  It does not put any files there, of course.

---

From: Glenn Bily <[email-masked]>
Date: Sun, 1 Sep 1996 23:45:52 -0400 (EDT)

> Mark,

> This doesn't answer the overall question...why is it there?

> --Glenn

> >> > 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.
> >
> >Current emacs does *create* the directory (ie. it is in the >package
> >contents), as recommended by the debian packaging >guidelines, as a
> >hint to the user that emacs will *look* there if there's >anything in

---

From: "Richard G. Roberto" <[email-masked]>
Date: Mon, 2 Sep 1996 23:58:45 -0400 (EDT)

> If it is suppose to be empty...Then why should it be at all?

Hmmm, i tend to agree here, except if Debian doesn't put it
there, I'm sure a slew of newbies will never figure out
where to put home grown stuff.  Perhaps creating
/usr/local/{bin,include,lib,man} and a README file explaning
what the heck it all is.

> > you decline to over-write a control >file.

No point in splitting hairs, etc is local already.  When we
start to over scrutinize things to this extent, we need to
ask ourselves what it it we really want to accomplish.
Doesn't /etc/ already accomplish this?  As far as using rcs,
I think its a good idea, but does it break some other
packages that offer a method for controlling and
distributing this information?  Maybe using /var/lib/RCS or
something and keeping this stuff unlocked.  That would give
dpkg the opportunity to have its own version information,
without encumbering other utilities.

> of choice code that could be used has already been written.

you lost me here.

> > around, that is possible.

If it keeps the md5sum around, can't it detect alterations?

> It should be the perogative of any Unix system to keep users out of root

I've never had the need to let any user muck around in the
root filesystem for any reason on any flavor on UNIX.  I'm
not sure I'm following this last part either ...

Thanks

Richard G. Roberto
[email-masked]
201-739-2886 - whippany, nj

--
*******************************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, offer or
agreement or any information about any transaction, customer account or account
activity contained in this communication.
*******************************************************************************