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 4FA5B2005163 for ; Mon, 11 Mar 2002 15:11:46 -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 16:04:57 -0500 Message-ID: <3C8D1D7E.40009@colubris.com> Date: Mon, 11 Mar 2002 16:11:26 -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: mbutcher Cc: 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> <20020311163104.C1D4E17224@www.aleph-null.tv> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Mar 2002 21:04:57.0328 (UTC) FILETIME=[663A6F00:01C1C940] 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: 612b8fde-e67b-4af6-b182-85b5abe39fd4 X-Archives-Hash: af542403aec8461bb8f783c6f62ed489 mbutcher wrote: > Interesting suggestions, but to me your solution looks more complex than the > status quo. Now, instead of just merging the files by hand, I have to: The idea I wrote is more to trigger more thoughts in hope of a better system than a real solution. My goal was to reduce works for most people while keeping it the same for the group of people that actually customized those. I'm pretty sure that most people here at first don't like my idea because I posted to -dev and therefore most of you will have custom scripts. But, because you have such scripts you already have the work of doing the merge therefore you don't lose anything. And you're more knowledgeable than others who can't/don't know how to customize those scripts. But right now the one who pay are the one who don't know. Because they have to do the merge and they are the newbies. > 1) Manage another set of scripts in another place (/etc/user.d), which makes > troubleshooting harder. We could actually have it inside the same place (using sym links) > 2) Deal with another set of config files (If I'm reading your second > paragraph correctly), which might break if a new ebuild adds or removes > options that this config file must have. It's not another set of config files. It's actually the distro set + the one your customized. So most users will only have the custom sets. > 3) Worry that any time I update a package, one of the scripts that _was_ > playing nicely will now be broken without giving me so much as a warning. That's true today also, aren't you worry that each time you emerge X11 it won't work anymore, or that each time you emerge baselayout it may break some basic application or binutils etc.. I mean the scripts are calling those application but if the application is broke the script also gets broke. I don't see this as a valid arguments for this discussion. If you claim that the script may get broke more than the program, I would not agree with you because I believe they are tested as much as the program themselves. (You may think that the program gets more tested but it only get tested inside gentoo on the same hardware/config platform as the people who also test their scripts.) > If we used your proposal for '.modif' scripts, then updating a build might > never warn us of the changes that _did_ take place, and _should_ be handled > differently in the custom script. If we added the functionality to portage to > warn us when a config script changed, then... well, we'd be back to where we > started. In that system where we would use sym links, if you customize a script and follow instruction, it would let portage detect that the file is a symlink and not a file and silently replaced it. If the file is not a symlink then it would act as if it was protected. Here I'm only talking about scripts not config files. If a scripts is also a config, then I would have mark as a bug to split them into a script and a config. Ideally you want to be warn when you did customize it not when you didn't. Right now the problem is that you always get and I think the big issue is that most people that get warns won't even know / figure out what to do exactly from that step on. While the one who customized their script will just need a reminder to check it out. > Also, I'd challenge the claim that 85-90% of Gentoo users do not alter their > init scripts. That may be true for Red Hat or Mandrake (though users of those > do have to update /etc/sysconfig files instead, which isn't any better to me). Look, My claim was not a fact. I think that this distro as great potential for anyone that used other linux distro for 1-2 years and are tired of waiting for distro update in order to update or try things out. Right now because the distro is below 1.0 I believe that most people using it are developers but I also believe that as you guys continue to enhance that system it will attract a lot more users who won't be developers. You probably already have seen that with the slashdot announcement (which is when I became a gentoo apprentice). > To me, the attractive part about the way it works now is that it is simple > and straightforward. I feel like I am in control of things when I update a > package. It took me (and probably most people on this list) a minimal amount > of time to learn the scheme, and now I rue the days when I used to spend > hours debugging problems in Red Hat init scripts (only to have my fixes > overwritten the next time I upgraded with RPM). Not really related, but feeling in control and being in control are very different thing. While you are in control becausse you can see the changes and analyse them think about those that don't know bash or that don't know that those scripts even exists, they won't even know why the new features they installed is not working even after the rc-update command has been issued. They will be even less in control than you wanted them to be at first. I agree it then offer a great opportunity to learn but that's what we call the hard way. I think that scripts should be treated as program, because that's what I think they are. If you silentely update program then why not silentely update scripts as well. That is my original issue. For some people customizing program is as frequent as the scripts themselves, would you warn them about each program modified? I don't think so, because they probably know their stuff. Therefore I think the same should apply to scripts. > I understand that the current way might slow you down if you're running a lot > of services. But to me, that's a small price to pay for soundness of mind and > simple elegance. I'm really happy with the distro, and I'm just trying to find spot for more enhancements. I even had realy hard time figuring out that one :-) because the distro is already great. Yannick Koehler