From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26421 invoked by uid 1002); 3 Nov 2003 02:01:20 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 13222 invoked from network); 3 Nov 2003 02:01:20 -0000 Message-ID: <3FA5B6EA.8050901@mcve.com> Date: Sun, 02 Nov 2003 21:01:14 -0500 From: Brad House User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030921 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gentoo-dev@gentoo.org, dhruba@codewordt.co.uk References: <3FA5AF6F.5030501@codewordt.co.uk> In-Reply-To: <3FA5AF6F.5030501@codewordt.co.uk> X-Enigmail-Version: 0.76.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [gentoo-dev] Vanilla behaviour in Gentoo Linux (long email) X-Archives-Salt: 555ad28d-3ae5-4827-8b56-ac1ac5ce41ab X-Archives-Hash: 05fad14f43f48810be585004d7ceba3c Commenting below: >> >> -------------------------------- >> Scenario 1: slocate and updatedb >> -------------------------------- >> >> 1) Remove slocate from base system >> 2) Remove makewhatis from daily cron duties >> 3) Remove updatedb from daily cron duties >> >> I'm probably not alone in the fact that I never use slocate and given >> fixed location of package files and other files in gentoo finding >> things is easier than other distros especially given qpkg -l and etcat >> -f. I do not agree with removing this stuff. I think it should be default. This is basic stuff that I've seen every other distro do as well, and I would consider this to be standardized. Though maybe what I would recommend doing is adding documentation in the install guide that will allow you to prevent this from being added to the cron, or removing from the cron. For those people who obviously don't know how to remove a cron job without complaining. >> >> ------------------------------------- >> Scenario 2: baselayout and /etc/issue >> ------------------------------------- >> 1) Eliminate /etc/issue and rename it if it must be added to the system >> no comment on this. This just doesn't bother me either way. Whatever. >> --------------------------------------------------- >> Scenario 3: vanilla kernels and development sources >> --------------------------------------------------- >> >> 1) Provide the kernel in vanilla fashion without customisations >> 2) Reconsider using the alsa and vanilla use flags here as they violates >> the rule of using use flags only for compile time switches. Ok, this I can comment on. development-sources has gone back to vanilla. The patches that were previously applied were only _stable_ driver patches. No controversial patches. Just to prove my point, only 1 out of the 6 patches _did not_ make it into 2.6.0-test9-bk7, and that was a large realtek 8169 driver patch. As for gentoo-dev-sources that is brand new which is meant to be a gentoo-patched version of the sources. This should _never_ get as bad as gentoo-sources though. I hope only stable multiplatform patches ever get added to this, otherwise stuff like amd64 will have to create another kernel. Johnm has assured me that it will only be a stable patch branch, mainly driver updates, not necessarily feature enhancements. The reason development-sources got patched in the first place was because amd64 requires 2.6 kernels, and the 2.6.0 vanilla sources would not compile on amd64, or had broken hardware drivers. So it was patched. gentoo-dev-sources has taken over this responsibility so as I said, it has gone back to vanilla. >> >> ------------------------------------- >> scenario 4: kernel sources on portage >> ------------------------------------- >> 1) Create gentoo patchsets only for finished releases and separate into >> different sources >> 2) Provide vanilla kernels as unaltered, unpatched and uncustomised >> sources just as they would be if done manually >> 3) Agree on prerequisites that must be fulfilled prior to adding new >> kernels-sources or in fact any new packages onto portage. I'm not sure what you consider a finished release. Is it not proper to patch a development release so it compiles on a platform? Otherwise what good is it. The general community probably doesn't have the know-how to patch it themselves to get it to compile/work. And I agree, there are too many source packages, and I think the reason for this is gentoo-sources having like 100 patches applied to it that are x86 only, and do not work on other platforms, so every other platform creates their own kernel tree, etc. The rest is covered in #3. >> >> ------------------------- >> Scenario 5: Ebuild speech >> ------------------------- >> 1) Eliminate all use of sleep in ebuilds obsurd. If you don't sleep after outputting messages, then it auto-unmerges an older package, or continues onto another packages, users will never see the usually important messages output to the screen. Also, your argument about gentoo claiming it gains 10s load-time, but having to wait 15s more for compile time is probably the most unintelligent argument I have ever heard. What the hell does compile time have to do with run time ... sorry, but at that point I totally lost respect for this message. >> 2) Eliminate all use of beeps via echo -ne "\a" If it really really really bothers you, unplug your pc speaker. Though I do not see a need for the bell either. >> 3) Write eclasses or modifications to portage which control logging and >> display - I have even written a bash wrapper (unfinished) around emerge >> which does log all output and displays all messages at end of every >> emerge separated according to package names. I agree there should be logging, but buffering? that I don't agree with. To output stuff at the end can take an extremely long time on a build like X or gcc. Unlesss I'm misunderstanding, that's ridiculous. >> 4) If there absolutely has to be sound it must be done through >> FEATURES="sound". FEATURES="notify" can be used for message waits if >> absolutely necessary. It's a shame that finally EULA's have made >> ebuilds interactive and sound and message waits are further increasing >> merge time ok... part of this is just, but please don't complain about EULAs. Complaining about free software, yes companies put stipulations on stuff they give away for free. In capitalist societies, people need justification for the work they do (compensation), etc. Don't complain if you have a free license to use it... Unless you're a programmer, you do not know what it's like to spend thousands of hours on something, then people complain about spending money on it. brad_mssw@gentoo.org -- gentoo-dev@gentoo.org mailing list