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

[Matthew Kennedy <mkennedy@gentoo.org>]

Dhruba Bandopadhyay <dhruba@codewordt.co.uk> writes:

> 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@gentoo.org mailing list
>
>

-- 
Matthew Kennedy
Gentoo Linux Developer

--
gentoo-dev@gentoo.org mailing list