Re: Removal of /etc/skel, your opinions please



On Fri, Nov 30, 2007 at 12:44:18PM +0000, Robert Watson wrote:
On Fri, 30 Nov 2007, Alexander Leidinger wrote:

Quoting Remko Lodder <remko@xxxxxxxxxxx> (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@xxxxxxxxxxx> (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
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.

I think that in addition to having "make distribution" populate /etc/skel
we should change useradd to take files from there instead of or
in addition to /usr/share/skel (I prefer "instead of" because at least two
of the files in /usr/share/skel are useless for the 99.999% of unix
users who don't read their mail with main(1)).

-- Brooks

[0] I've met one person who used main(1) with serious intent.

Attachment: pgpft5LTRzxuX.pgp
Description: PGP signature



Relevant Pages

  • Re: Removal of /etc/skel, your opinions please
    ... 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. ... 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. ...
    (freebsd-arch)
  • Re: Removal of /etc/skel, your opinions please
    ... I would like to remove /etc/skel from the BSD.root.dist mtree file since ... installed, manage this through "mergemaster") is install all files from ... adduser instead. ... Sounds like a quite reasonable argument could be made for having mergemaster ...
    (freebsd-arch)
  • Re: make installworld fails
    ... I know that updating requires the mergemaster steps because I read the ... % To rebuild everything and install it on the current system. ... % you boot into single user mode to do the installworld. ... `make installworld' with an old kernel and have it blow up, ...
    (freebsd-questions)
  • Re: About mergemaster (Re: upgrading)
    ... > mergemaster on a CVS mirror, you're not going to be able to get at it. ... That's why a simple hash of the file, which could be generated at install is ... a more sophisticated compare mechanism. ...
    (freebsd-stable)
  • Re: /usr/src/Makefile instructions
    ... both with mergemaster and the ports. ... The latter case may be somewhat more complicated: install a fresh ...
    (freebsd-hackers)