From owner-freebsd-arch@FreeBSD.ORG Fri Nov 30 19:57:48 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F9CB16A419; Fri, 30 Nov 2007 19:57:48 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 839E713C4F5; Fri, 30 Nov 2007 19:57:47 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A55984.dip.t-dialin.net [84.165.89.132]) by redbull.bpaserver.net (Postfix) with ESMTP id 917662E3AC; Fri, 30 Nov 2007 20:54:22 +0100 (CET) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id 581B0765ED; Fri, 30 Nov 2007 20:54:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1196452457; bh=8fwA3i7cqD3p3Ema2XPBaK12S2DGXs1QW FsxdCHt6Zc=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To: References:X-Mailer:Mime-Version:Content-Type: Content-Transfer-Encoding; b=m/p3BAsSofaVKP2sQZe4xhnbIEIjmW9RPHOWC QVU/DkLUrsnj7/jWbdy+MoF45QCxIY/Flne5gknXtduUHRSWbF+Hkx4tUnHJIsgnP3G PS6R9l/MwfWrhQnEEpIWWNzE8dnfdEfdNC9F6jrEMPECJ2hmPwvZQFeobqTTsZ0kkN2 pA+Jp0gM/wnOnGd5ZPQUZeJPq8m/Gql+sgENFBBrNK3lE7lXP5XZabp63NYUXwqjUpx /4PetGwGlNM1gq3Z9JjGRazJ4eL8qHYiRI4vnuac5gENZljz2LPt90t/pgHyf1jpI8/ GDE3K7hJEn6ObcBeYfI6aaLzwDKtxiYhpGIDA== Date: Fri, 30 Nov 2007 20:54:11 +0100 From: Alexander Leidinger To: Robert Watson Message-ID: <20071130205411.59046e41@deskjail> In-Reply-To: <20071130124258.P56931@fledge.watson.org> References: <17978.194.74.82.3.1196407530.squirrel@galain.elvandar.org> <20071130101651.4h9nvpztkwcg8o84@webmail.leidinger.net> <20071130124258.P56931@fledge.watson.org> X-Mailer: Claws Mail 3.0.1 (GTK+ 2.10.14; i686-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-15.4, required 6, autolearn=not spam, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, RDNS_DYNAMIC 0.10, SMILEY -0.50) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: Remko Lodder , freebsd-arch@FreeBSD.org Subject: Re: Removal of /etc/skel, your opinions please X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2007 19:57:48 -0000 Quoting Robert Watson (Fri, 30 Nov 2007 12:44:18 +0000 (GMT)): > On Fri, 30 Nov 2007, Alexander Leidinger wrote: > > > Quoting Remko Lodder (from Fri, 30 Nov 2007 08:25:30 > > +0100 (CET)): > > > >> On Thu, November 29, 2007 10:47 am, Alexander Leidinger wrote: > >>> Quoting Remko Lodder (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