On Mon, Nov 03, 2003 at 01:29:19AM +0000, Dhruba Bandopadhyay wrote: > 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 > --------------------------------
Many, many users use locate and many would complain if it was missing. Every distribution I've used considers slocate to be part of a pretty basic install and places it in the daily cron jobs. If you don't want it there, rm /etc/cron.daily/locatedb.cron and you're all set. > > ------------------------------------- > 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: This is an example of expected behavior not necessarily fitting what you, personally, expect. I'm sorry, we can't cater to everyone: if it's there, some people go "I don't want it," if it's not there, some people go "I want it" -- I, frankly, think it should stay. It's not harming anything, unless that 4k (unless you use a different blocksize) is really killing you. > > 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 Already removed and moved to gentoo-dev-sources or something like that. > 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 Yes. And the install guide specifically recommends gentoo-sources or vanilla-sources. Who's confused? > > 1) Create gentoo patchsets only for finished releases and separate into > different sources Unfortunately we have situations where we need driver patches for 2.6, for example. This is why there's a gentoo-dev-sources. There are other similar situations. > 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. Wait, wait, wait - I thought you were upset because we weren't letting users make choices? Now you're upset because we're offering too many choices? > > ------------------------- > 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 Except that it sleeps for _very important messages_. Those timers are there because people were totally missing those messages. -- Jon Portnoy avenj/irc.freenode.net -- [EMAIL PROTECTED] mailing list
