Hubert Feyrer wrote:

> On Fri, 29 Sep 2000, Simon Burge wrote:
> 
> >  + merge /usr/share/skel and /usr/share/examples/usermgmt into
> >    /usr/share/skel (I think this name makes more sense than
> >    usermgmt).
> 
> OK.
> 
> >  + add a "make distribution" target to share/skel/Makefile to
> >    install the examples into /etc/skel.
> 
> And ship with an identical set of skel files in both /etc/skel and
> /usr/share/skel?
> 
> The problem solved here is how it's done in pkgsrc: install an example
> file, and let the user copy it over to the real location. That's not
> what's being used in the base system. In the base system, the etc-set
> contains all files that are customizable by users/admins, and the skel
> files should be part of that. That way, noone will overwrite his
> customized skel files on an upgrade (assuming he doesn't extract the etc
> set there).
> 
> I'd therefore say: put the skel files into either /etc/skel or
> /usr/share/skel, and make them part of the etc set. I don't have a
> preference on which dir, but useradd may need adjusting.

Hmm, I'd tend towards /etc/skel - all of /usr/share should be shareable
amongst a cluster of machines, and that may not be possible for whatever
reasons.

Actually, you can set (the undocumented!) skel_dir in
/etc/usermgmt.conf, so yes, why don't we just put everything into
/usr/share/skel and the user can then put customised files in /etc/skel
if they want to without fear of them getting overwritten.

It is possible for the pkgsrc version to work this way?

And Chris G. Demetriou wrote:

> this sounds like it might be reasonable... but copying them into /etc
> makes it more likely that they'll be overridden during an upgrade.

Would you be happy with the above?

> would it make sense to search /etc/skel and /usr/share/skel?

It's not quite a "search here and then there" model.  It just copies
(with pax) the contents of one directory and then another.  Unless you
meant copy all of /usr/share/skel and then all of /etc/skel...

Simon.
(off to document skel_dir!).
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD Sales, Support and Service:  http://www.wasabisystems.com/