Removal of /etc/skel, your opinions please

[Alexander Leidinger]

Quoting Robert Watson <rwatson at FreeBSD.org> (Fri, 30 Nov 2007 12:44:18 +0000 (GMT)):

> On Fri, 30 Nov 2007, Alexander Leidinger wrote:
> 
> > Quoting Remko Lodder <remko at FreeBSD.org> (from Fri, 30 Nov 2007 08:25:30 
> > +0100 (CET)):
> >
> >> On Thu, November 29, 2007 10:47 am, Alexander Leidinger wrote:
> >>> Quoting Remko Lodder <remko at FreeBSD.org> (from Wed, 28 Nov 2007
> >>> 22:21:06 +0100):
> >>> 
> >>>> Dear arch@ members,
> >>>> 
> >>>> I would like to remove /etc/skel from the BSD.root.dist mtree file since 
> >>>> it is no longer being used and I would like to remove unused items.
> >
> >>> Not an objection, just something to think about: Do we want to deprecate 
> >>> the use of "adduser -k /etc/skel"? I know you said you just want to remove 
> >>> the directory, and every admin is allowed to create it again, but by 
> >>> removing the directory from the mtree file, we give a signal into the 
> >>> direction of deprecation.
> >
> >> You do have a point there actually :-), what we can do in the install phase 
> >> (initially "make distribution", later on when the system is already 
> >> installed, manage this through "mergemaster") is install all files from 
> >> /usr/share/skel to /etc/skel and actually use it.
> >> 
> >> If we dont want to do that, why should we keep on carrying the directory 
> >> then?
> >
> > I have a local patch to adduser which adds /usr/local/share/skel (so 2 
> > directories are used by default). Now I think it may be better to change 

Ooops... I misremembered, the patch is not about -k, it adds plugins to
adduser instead (execution of programs during the execution of adduser).

> > this to use /etc/skel instead, and to do it in a way that /etc/skel 
> > overrides /usr/share/skel. Looks more usable to me. What do you think?
> 
> Sounds like a quite reasonable argument could be made for having mergemaster 
> install and manage /etc/skel so that when sites customize /etc/skel, 
> mergemaster can be used to manage those customizations over time. 
> Alternatively, mergemaster could manage /usr/share/skel.

Having /usr/share/skel managed my mergemaster is a little bit ...
strange for me.

I think I need to clarify what I wrote. My idea is to first look
at /usr/share/skel and install those files, and then to look
at /etc/skel and install these files. So if nobody changes something,
you get the files we ship, and when you put a modification
in /etc/skel, it will overwrite what was installed
from /usr/share/skel. This doesn't handle the case where an admin
removes a file from /usr/share/skel. This can be handled by putting
such files with just a comment inside into /etc/skel. I looked at
adduser.sh and it just gives the skel directory to pw, so pw needs to
be changed for this.

This way you wouldn't need to let mergemaster handle anything, as the
installworld will install the /usr/share/skel part, and the admin can
override what is installed. One drawback compared with the mergmaster
handling is, that he has to look for changes himself in case he did
only a small modification.

I don't know about any complains from users regarding the current
behavior in /usr/share/skel, so this small extension may be sufficient
for us. I have no strong opinion about this part (often I use vipw
instead of adduser for local users).

Bye,
Alexander.

-- 
I'm mentally OVERDRAWN!  What's that SIGNPOST up ahead?  Where's ROD
STERLING when you really need him?
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137