From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DMARC_MISSING, MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=4.0.0 Received: from rearviewmirror.org (sense-sea-CovadSub-0-150.oz.net [216.39.147.150]) by chiba.3jane.net (Postfix) with SMTP id E7BE2200D0DE for ; Mon, 11 Mar 2002 16:19:41 -0600 (CST) Received: (qmail 29732 invoked by uid 1000); 11 Mar 2002 22:16:25 -0000 Date: Mon, 11 Mar 2002 14:16:25 -0800 From: Matt Beland To: gentoo-dev@gentoo.org Subject: Re: [gentoo-dev] /etc/init.d Message-ID: <20020311221624.GF28735@rearviewmirror.org> References: <3C8CEDD8.2000907@colubris.com> <20020311180248.GB1380@littlethulu.craigthulu.com> <3C8CF48D.5000106@colubris.com> <20020311185408.GC28735@rearviewmirror.org> <3C8D1715.8010001@colubris.com> <1015881023.7117.24.camel@nosferatu.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VuQYccsttdhdIfIP" Content-Disposition: inline In-Reply-To: <1015881023.7117.24.camel@nosferatu.lan> User-Agent: Mutt/1.3.25i Sender: gentoo-dev-admin@gentoo.org Errors-To: gentoo-dev-admin@gentoo.org X-BeenThere: gentoo-dev@gentoo.org X-Mailman-Version: 2.0.6 Precedence: bulk Reply-To: gentoo-dev@gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux developer list List-Unsubscribe: , List-Archive: X-Archives-Salt: 7064afdd-29b4-4965-ac66-58aa24992494 X-Archives-Hash: b7d0cb0fed44a39a0fd9ae8a13c24ef3 --VuQYccsttdhdIfIP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 11, 2002 at 11:10:14PM +0200, Martin Schlemmer wrote: > On Mon, 2002-03-11 at 22:44, Yannick Koehler wrote: > > Matt Beland wrote: > > > > > > They are sometimes both scripts and config files. Personally, I like = the=20 > > > layout of the Gentoo initscripts, particularly with regard to the "lo= cal" > > > script and the ability to start "simple" daemons and scripts with a c= onfig > > > file. However, many of the scripts we add to the init.d directory are= not > > > custom-written for Gentoo, they're written for Linux in general. They= =20 > > > include the necessary config settings in the init file itself. And th= ose > > > should not be clobbered. > > > =20 > >=20 > > While I understand that by having seen some of those scripts in the=20 > > past, I don't see a reason not to either do work by removing those=20 > > 'config' part and moving them to a /etc/ file and then committing a=20 > > patch into gentoo or the original package owner. I'm pretty sure doing= =20 > > so wouldn't be considered gentoo either. I've seen some distro doing= =20 > > that inside most of their init scripts in order to ensure no one play= =20 > > with them directely and kind of filtering the dangerous settings from= =20 > > the config file (always by warning the end-user thought through a log o= r=20 > > something like that). > >=20 But we're not talking about Gentoo init scripts, necessarily. If the script= was installed by some program, and there's no build for it nor is there any real interest in creating an ebuild for it, then why create a config file and al= l of this extra effort you're proposing for what may be a very simple script. If the program is not part of an ebuild, you might not notice emerge clobbering your script thanks to an unfortunate collision in the script name. > Once again ... if you have everthing latest, you should not need to edit > a file in /etc/init.d/ . All the config settings is in /etc/conf.d/ . > This should anyhow go for most users who do not have a unusual setup. I am not necessarily referring to Gentoo programs or scripts. I am aware th= at the Gentoo init scripts, as designed, do not require any protection. The is= sue is init scripts that are created for some other daemon not installed as part of Gentoo potentially being clobbered by a Gentoo-installed script. > > > That's fine for things like the tweaked pcmcia script - but what if t= he=20 > > > tweaks are in order to permit a specific driver to work properly? Tho= se=20 > > > changes should not be in the default initscript, they should at most = be > > > provided as a commented-out section - which, again, would require use= r=20 > > > intervention to create the required "tweaked" script. > >=20 > > I don't agree here. If you have script that make a piece of hardware= =20 > > work they should get committed inside Gentoo. Otherwise other people= =20 > > that have the same issues won't be able to make it work either. If it'= s=20 > > for a specific hardware combination then why making all other users= =20 > > spend their time diff/mv files while you'll be the only one with that= =20 > > problem? Because this is *one example* of an issue which creates problems. It is not= =20 an exclusive problem where this is the only time it would create a problem. I updated my workstation and two test Gentoo boxes last night, including=20 baselayout changes. It took an extra minute maximum per box to look through the scripts, identify the two that might be a problem, and update the rest. I hardly think that's a terrible burden to assume. > > Also having something like I mentionned called user.d where you could= =20 > > put your own script file would be resolving that. Maybe even better=20 > > would be to have gentoo write scripts by default to system.d and have= =20 > > symlink inside init.d so that if it attempt to copy a script inside=20 > > init.d and see that it's not a link to a system.d files then it doesn'= t=20 > > override it and warn instead. The whole idea could also be used for th= e=20 > > /etc folder completely. It would resolve the problem but break compatability with every other Linux= =20 distribution.=20 > > > > Actually I think the opposite. Convenience for me is really important.= =20 > > The less I have to do the more I'm happy and can do something else.= =20 > > That's why I'm complaining at the first place. I've merge a couple of= =20 > > time baselayout and while this package shouldn't be updated frequentely= =20 > > IMHO it shouldn't be kept idle either if it can still be enhanced.=20 > > Therefore I think to make the thing more convenient and less annyoing w= e=20 > > should enhance it a little more. Quite franky, convenience should never be given priority in cases like this. System updates should be as convenient as possible *without compromising the system*. We're not talking about making it easier to read your email, we're talking about modifying a core system directory with files that are critical to the proper operation of the system. Convenience is and should always in such cases be secondary to stability and security. --=20 Matt Beland matt@rearviewmirror.org http://www.rearviewmirror.org --VuQYccsttdhdIfIP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8jSy4BxcVTa6Gy5wRAtXcAJ9lI3MakJ1BD4AGj3f+tVjdTocgQQCg+R6t qQkQ/7O0y/RPBVZeIlBEkSk= =bbPE -----END PGP SIGNATURE----- --VuQYccsttdhdIfIP--