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 exchange.colubris.com (gate.colubris.com [206.162.167.230]) by chiba.3jane.net (Postfix) with ESMTP id BBDDF2015DB2 for ; Mon, 11 Mar 2002 17:28:20 -0600 (CST) Received: from colubris.com ([192.168.30.147] RDNS failed) by exchange.colubris.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 11 Mar 2002 18:21:31 -0500 Message-ID: <3C8D3D80.1060806@colubris.com> Date: Mon, 11 Mar 2002 18:28:00 -0500 From: Yannick Koehler User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020218 X-Accept-Language: en-us MIME-Version: 1.0 To: gentoo-dev@gentoo.org Subject: Re: [gentoo-dev] /etc/init.d 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> <20020311221624.GF28735@rearviewmirror.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Mar 2002 23:21:31.0953 (UTC) FILETIME=[7A9AFA10:01C1C953] 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: bbafcb7c-8df1-4133-8ab3-9e319d71e162 X-Archives-Hash: ca3c34efa91c38721b33f7af55ea1be9 I now have my solution so I'm mostly arguing just for the fun of it now ;-) Matt Beland wrote: > 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 >>>>layout of the Gentoo initscripts, particularly with regard to the "local" >>>>script and the ability to start "simple" daemons and scripts with a config >>>>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 >>>>include the necessary config settings in the init file itself. And those >>>>should not be clobbered. >>>> >>>> >>>While I understand that by having seen some of those scripts in the >>>past, I don't see a reason not to either do work by removing those >>>'config' part and moving them to a /etc/ file and then committing a >>>patch into gentoo or the original package owner. I'm pretty sure doing >>>so wouldn't be considered gentoo either. I've seen some distro doing >>>that inside most of their init scripts in order to ensure no one play >>>with them directely and kind of filtering the dangerous settings from >>>the config file (always by warning the end-user thought through a log or >>>something like that). >>> > > 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 all 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. > The same occurs if I create a software and I give it a name and inside a package there's a binary with the name which obviously will get over my /usr/bin file. The chance are probably the same. If you write binary you'll have this problem, if you write script, well... you'll have the problem too. Try to compare both ... believe it or not I may write 1-2 utilities for my testing per week and name clashing can occurs as I'm not the only one working on the cvs repository we use. The trick, well, I move my stuff into my own folder and I create sym links, the same trick can safely be done in /etc/init.d. I don't see a complication in there, most people that customize script surely know about sym links. At least this way it's easy for me to figure out if my exe are mine or someone else. >>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 that > the Gentoo init scripts, as designed, do not require any protection. The issue > is init scripts that are created for some other daemon not installed as part > of Gentoo potentially being clobbered by a Gentoo-installed script. But I don't see what's wrong with that. Again the same could be occurring with a binary and it may take a certain time before someone figure it out. The chance of that occuring are as unlikely for script that they are for binary because some people do test and find out that there's file being overwritten. At least in that case only interested parties (the one with the script in use through rc-update) gets affected. And not all other users who don't use that script while still using the 20-25 other scripts inside init.d > > >>>>That's fine for things like the tweaked pcmcia script - but what if the >>>>tweaks are in order to permit a specific driver to work properly? Those >>>>changes should not be in the default initscript, they should at most be >>>>provided as a commented-out section - which, again, would require user >>>>intervention to create the required "tweaked" script. >>>> >>>I don't agree here. If you have script that make a piece of hardware >>>work they should get committed inside Gentoo. Otherwise other people >>>that have the same issues won't be able to make it work either. If it's >>> for a specific hardware combination then why making all other users >>>spend their time diff/mv files while you'll be the only one with that >>>problem? >>> > > Because this is *one example* of an issue which creates problems. It is not > 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 > 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. I won't go and argue on how much time it takes. It all depends on what's occuring and who's behind the screen. What I'm saying thought is that right now, the way it's done it's more prone to broke a system and get the newbie running than helping him out while doing the reverse may not affect the experienced greatly while helping the newbie a lot. > >>>Also having something like I mentionned called user.d where you could >>>put your own script file would be resolving that. Maybe even better >>>would be to have gentoo write scripts by default to system.d and have >>>symlink inside init.d so that if it attempt to copy a script inside >>>init.d and see that it's not a link to a system.d files then it doesn't >>>override it and warn instead. The whole idea could also be used for the >>>/etc folder completely. >>> > > It would resolve the problem but break compatability with every other Linux > distribution. Euh, I'm talking about gentoo here, people are interested to run the same init script, / partition for other distro at the same time? But even then it probably would work as sym link are kernel/fs thing and not distro related. Therefore the script would get executed as long as the target for the link exists. Also the operation of moving the script inside a system.d folder is a gentoo thing and would only be doable from an ebuild script. scripts coming out of tarball would be treated as if they were custom and therefore they won't be a symlink and gentoo would not overwrite them because of that. (if it's done like I mentionned previously) > >>> >>>Actually I think the opposite. Convenience for me is really important. >>> The less I have to do the more I'm happy and can do something else. >>>That's why I'm complaining at the first place. I've merge a couple of >>>time baselayout and while this package shouldn't be updated frequentely >>>IMHO it shouldn't be kept idle either if it can still be enhanced. >>>Therefore I think to make the thing more convenient and less annyoing we >>>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. > > If you do emerge without looking into each file that got changes then your system may have been compromised. I mean I can write a ebuild make a single syntax error inside a domain entry for the file, and buy that domain and get the file in there and you'll download it like most people once its approve and you'll get a buggy version which will compromise your system. If your only put attention to what you put in /etc don't think you're system is ok. Yannick Koehler