From owner-freebsd-rc@FreeBSD.ORG Tue May 10 04:08:27 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 724E1106566B; Tue, 10 May 2011 04:08:27 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1A4FB8FC14; Tue, 10 May 2011 04:08:26 +0000 (UTC) Received: by iyj12 with SMTP id 12so6974577iyj.13 for ; Mon, 09 May 2011 21:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=tGGQTHxJDGsktMuhjz0WIzf4oA/nkEo19+KLljL87Sc=; b=g9UzQC0AkVzihVe+pxqhX84gG8jpzNHhAzr4kwB1l4VClyv6pH/IrBOCPIFP6hPdb8 zzuW640bfypfU4M/YjIWQZNeekouihuZCK7btcm+48LT6qKwTwtNPIIB+lyl3+5Nd0u/ tgjCkEo8KKvtvt0XjvDqAP3jYS5wIGgiEObyQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=h5Ht+3rGI8sD2MJmdpkNw9Ny7iy0TpL14oxE9sMPx9fFd6aeKR+rIVuAZFcXGt0nVk 713QftKv/VkP7rmBwfeoui5GTL8PfBW2C5ICB87nviJSrz2Ctq8DOvgy8iWSiNzitvmd lO3MX8UPFC69JenEeoApj9qNyXg0jq5ZVFq+I= Received: by 10.42.54.82 with SMTP id q18mr6592901icg.311.1305000506455; Mon, 09 May 2011 21:08:26 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id jv9sm2687766icb.1.2011.05.09.21.08.24 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 21:08:25 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p4A48M8T028527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 May 2011 00:08:22 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p4A48MHm028526; Tue, 10 May 2011 00:08:22 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Tue, 10 May 2011 00:08:22 -0400 From: Jason Hellenthal To: Doug Barton Message-ID: <20110510040822.GB18435@DataIX.net> References: <20110508191336.GC3527@DataIX.net> <4DC84E68.1000203@FreeBSD.org> <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> <4DC8787A.9070003@FreeBSD.org> <20110509235746.GC2558@DataIX.net> <4DC8A592.2090202@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WYTEVAkct0FjGQmd" Content-Disposition: inline In-Reply-To: <4DC8A592.2090202@FreeBSD.org> X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 04:08:27 -0000 --WYTEVAkct0FjGQmd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Doug, On Mon, May 09, 2011 at 07:40:18PM -0700, Doug Barton wrote: > On 05/09/2011 16:57, Jason Hellenthal wrote: > > > > Doug, > > > > On Mon, May 09, 2011 at 04:27:54PM -0700, Doug Barton wrote: >=20 > > Sorry Doug but rc.conf.d is already laid out for the user to use as > > mentioned by rc.conf(5) with a suggested use but unfortunately has quit= e a > > few side effects that I am not going to bother re-writing about again. >=20 > I read what you have written to date, but I don't see anything other=20 > than "It doesn't work the way I want it to." I just re-read the=20 > description in rc.conf.5, and I think it's clear, but I wouldn't object= =20 > to suggestions to improve it. >=20 > > In reply to your previous email here is one exercise that should point > > out the broken functionality fairly clearly or at least I hope clearly > > enough that you realize how a normal user would look at it. > > > > From scratch, no rc.conf. >=20 > No normal user would do that, so I reject your premise. :) >=20 Ok let me re-state that because you seem to have taken that litterally as= =20 absolutely no rc.conf. "A rc.conf but without the needed nfs related=20 parts" This is an example!. > > Setup a NFS server with lockd, statd, mountd, > > rpcbind using only rc.conf.d/${_name} namespace and then try starting > > these services using service(8) and /etc/rc.d/* files. Then read > > rc.conf(5) and tell me the suggestion for jail makes sense. >=20 > The various nfs-related options are a particularly pathological case, no= =20 > one is disputing that. However, for the vast majority of purposes the=20 > one-name-at-a-time method works fine. And given that most users don't=20 > need anything even approaching the type of functionality that you're=20 > proposing, I still don't see a problem. >=20 I was not asking your you opinion of the way it works. You asked for an=20 example and one was given and you seem to be all opposed to even going=20 through and testing out that example to see where the stumbling blocks are= =20 as you apparently have no recognition of them now. NFS is not the only case. > > If you still disagree after doing this then please by all means eradica= te > > rc.conf.d from rc.conf(5) and remove its functionality from rc.subr as = it > > is less than adequate for anybody other than a developers natural use. >=20 > I hope you'll understand if I politely decline your request. >=20 I was not expecting anything less than your typical response. > > I do not quite understand why you take such an opposition against > > something that fixes this broken functionality but yet retains its > > original use. >=20 > Gordon has already stated it fairly eloquently, but I'll paraphrase. Too= =20 > much potential for user confusion, for too little benefit. I realize=20 > that to you this sounds like a simple change, but the problem is that=20 > when you add knobs, users twist them. So every change to something as=20 > fundamental as the boot system needs to have really strong justification. >=20 Sadly at this point you still seem to not realize the complicated state=20 that rc.conf.d is in. This is not adding a new knob and you seem to miss=20 that part as well. This fixes that complication on the rc.conf.d directory= =20 and it could be properly implemented in a way that it should have been in= =20 the first place as the manual suggests. What do you propose to do with the manual page ? can you sum that up for=20 me please ? I would be quite interested in how you or anyone for that=20 matter explain properly how this is actually working. --=20 Regards, (jhell) Jason Hellenthal --WYTEVAkct0FjGQmd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNyLo1AAoJEJBXh4mJ2FR+Gj4IAKAPFBFn5gV1RJ+NU125EG1v zrOq9BXac/0I5dlIV5PzreEEmMU4GRHAMRBi9UZ2j0joip+CiWt5QumSKOkm7ABw 7CCpQUS/hjretxoph7anAiU0gXonc7tlIcXmW4c70ne/Z+2CWphqimSzm8CbkSaB 1F1jc2tia2kePNWUAfRHYi2k8m6CToGbQKKvK4Eii9DQoD0Vo7sQf3qH7ptcKhgh QPrOFDggWoUwjb96XAyVXLor4DAUKhxUgfc/F/LUYn3ddif+H7ltwq36bNAIjqgx UDSSR1wFEBcxMgq9DZ1IzkhexUzFmrhu2oKm7uYov2sgVKIApgAqxKWhiq6BOEc= =dmUL -----END PGP SIGNATURE----- --WYTEVAkct0FjGQmd--