[gentoo-dev] Vanilla behaviour in Gentoo Linux (long email)

[Dhruba Bandopadhyay]

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
<snip>
$ 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@g.o mailing list