From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25046 invoked by uid 1002); 3 Nov 2003 01:28:17 -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 9207 invoked from network); 3 Nov 2003 01:28:17 -0000 Message-ID: <3FA5AF6F.5030501@codewordt.co.uk> Date: Mon, 03 Nov 2003 01:29:19 +0000 From: Dhruba Bandopadhyay Reply-To: gentoo-dev@gentoo.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gentoo-dev@gentoo.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [gentoo-dev] Vanilla behaviour in Gentoo Linux (long email) X-Archives-Salt: cddd9b21-fa92-4b8d-bccf-69ed9a7497e5 X-Archives-Hash: ff3c9528f1ef2b70a72102972c280550 Hello I'm writing about the enforcement of default/expected 'vanilla' behaviour of various attributes of the operating system. These issues have been an annoyance for some time and are only being ventilated now that I have some time so please forgive me if I seem a little edgy. My intention is to make suggestions and reach discussed optimal solutions. When reading bear in mind the philosophy of putting control into the user's hand and providing choice to the user. -------------------------------- Scenario 1: slocate and updatedb -------------------------------- Out of the blue my hard drive starts roaring flat out. This happens generally after the first reboot after installation or every day on a working system. Given that this happens without any prior warning or any explicit consent or instruction during any part of install or configuration it can become extremely unpleasant especially if doing something rather important and resource intensive. The culprit here is slocate and the makewhatis and updatedb cron scripts added to the daily cron duties! One of the reasons I use Linux is because it only does things when I tell it to. Problems like this one sadly resemble Windows which when idle begins to grind away at hidden activities. updatedb also requires root access to kill which can be an added hassle. My requests: 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. ------------------------------------- Scenario 2: baselayout and /etc/issue ------------------------------------- With every emerge or update of baselayout or invocation of emerge -e a file called /etc/issue is placed on my system. It serves no purpose other than to tell me what I already know such as what kernel, architecture and machine name I am using. And on server machines with no monitor it does not even do that much. Every time I have to delete this file and it gets added back in later. Is this an example of developer preference deviating from vanilla behaviour? There have been bugs filed about the removal of graphical /etc/issue which was later removed. Why not give the user the choice and put control in his or her hands? Customisation is a preference. My requests: 1) Eliminate /etc/issue and rename it if it must be added to the system --------------------------------------------------- Scenario 3: vanilla kernels and development sources --------------------------------------------------- Usually, I get the latest bk snapshot from kernel.org, unpack and compile manually. However, recently, on a new install I emerged development-sources to fulfill virtual/linux-sources and was later puzzled to find its contents in /usr/src/linux/linux-2.6.x-test-y-patchset-a.b and many other involuntary steps being taken by the ebuild. This confounded many users and bugs were filed about install locations, alsa actions and also about adding gentoo patchsets to dev-sources. On forums, I heard something about a 'vanilla' use flag to prevent the gentoo patchset although now I only see it in IUSE and not in emerge -vp oddly. Why can't it be as simple as download > unpack > merge rather than download > unpack > play with permissions > run genpatches to patch sources > merge into different location? What is the 2.6-test gentoo patchset and why is it necessary and applied by default on an unfinished release? My requests: 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. ------------------------------------- scenario 4: kernel sources on portage ------------------------------------- $ emerg -qs sources $ emerge -qs sources | grep -c '^*' 38 Currently, there are 38 kernel sources on portage. A few weeks back there were 36. Then gentoo-test-sources was added as a branch to gentoo-sources and also recently gentoo-dev-sources has been added as a branch to development-sources. Now, does this only strike me as being a very large number resulting from liberal means? Are there any rules that govern creating new kernel sources and justifying their need? Providing choice is good but having this many kernel sources not only confuses the user and makes him indecisive but it also makes dev maintenance and administration more difficult. Also, problems such as the description for gentoo-dev-sources being exactly the same as development-sources will only serve to increase confusion. Is it necessary to provide gentoo patchsets for every possible kernel variant? Even if you go by the rule that stable kernels will have patchsets the current dev-sources violates it. My requests: 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. ------------------------- Scenario 5: Ebuild speech ------------------------- On completion of merging the portage ebuild sleeps for ~15 seconds, the baselayout ebuild for ~10 seconds and even dev-sources sleeps for ~5 seconds whilst all these packages display messages. In my opinion, this is downright pointless. On a source distribution like this one especially where claims about speed are made not only of portage but also the packages themselves what is the point in gaining ~10 seconds load time when you lose ~15 seconds compile time? What is the net gain? To make matters worse, ebuilds beep out loud through pc speaker on important sys-apps merges whilst sleeping in between which can make one very uncomfortable in office or quiet environments. I understand it is important to get messages to the user but this is not the way. There should be other means whereby all messages are accumulated and logged and displayed at the end of all merges (bugs are open). I currently this as follows. $ emerge -Du world | tee updates.log $ grep '01m' updates.log ( <-- this gives all messages in log file without use of sleep) My requests: 1) Eliminate all use of sleep in ebuilds 2) Eliminate all use of beeps via echo -ne "\a" 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. 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 Overall, I would say vanilla behaviour should always be exhibited by default in all aspects of the operating system in favour of user preference or dev preference. Focus should be on instructing the user on how to make a change rather than making the change and expecting the user to reverse it. Exceptions are where the change is vanilla in itself like providing stock kernel configs to newbie users as genkernel does. Please discuss as you wish. I would be grateful if these issues were paid some attention and I look forward to receiving feedback whether you share the same experience or have opposing views. If any of them should be filed as bugs with sincere regards Dhruba Bandopadhyay -- gentoo-dev@gentoo.org mailing list