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

[Chris Smith <chris.rs@xtra.co.nz>]

On Monday 03 November 2003 14:29, 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.

Ok, my reply isn't quite as long, but I attempt to address all the issues that 
you bring up. My views expressed here are IN NO WAY anything to do with the 
views of Gentoo Linux, as I am just a user. My replies are based on what 
Gentoo Linux means to me.

> --------------------------------
> 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.

slocate, updatedb and makewhatis are standard UNIX commands/programs. It's 
basically "compatability" so that a user from redhat can log into a Gentoo 
server and still find his way around. In my opinion, the user shouldnt have 
to edit any configuration file to have a functional Linux system, which is 
reasonably compatable with almost any other distro.

Instead, for you to get the system the way you want it, you must edit the 
configuration files. If you don't use slocate, there is nothing at all 
stopping you from editing the cron.daily file and removing its entry. This 
way, another distro user can come in and use most of the commands he's used 
to. Now the thing is, the control IS in the hands of the user, you can change 
your system anyway you want, but I argue that Gentoo should retain standard 
UNIX utils. Even Debian provides this functionality by default.

> -------------------------------------
> 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

Again, why should the entire distro use (or not use) something that you don't 
want.

chris@chris chris $ ls -alo /etc/ | grep issue
-rw-r--r--    1 root           30 Sep 25 09:46 issue

are you really missing those 30 bytes? Does the system information at login 
really rub you up the wrong way?

If its that much of a problem, just: ln -s /dev/null /etc/issue

Also, I think now you are arguing that vanilla behaviour should be followed, 
but in the previous scenario you were arguing that we should deviate from 
standard Linux procedures.

> ---------------------------------------------------
> 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.

I really don't know what's going on here. But I'm absolutely sure thats what 
the vanilla-sources package is there for. If you want a vanilla test kernel, 
development-sources. 

I personally don't see a problem here, as number 1 in your request is already 
in place. Lots of kernel packages == lots of choice.

Also, I thought use flags were to enable features in packages. Where does it 
say it's compile time only? Perhaps it should be changed to a more general 
definition, as I think the use flags are the best way to handle things.

> -------------------------------------
> 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.

1) Why? A lot of Gentoo users (probably more so than any other distro) use 
development kernels, and the Gentoo patchset provides a lot of functionality. 
Have a look at the popularity of "love-sources" on the forums.
2) As far as I know, they are. I use a variety of kernels and when I use the 
"vanilla-sources", thats exactly what I get, vanilla kernel sources.
3) Care to elaborate on this some more? There is a variety of criteria that 
has to be complete before ebuilds are added to portage. Please elaborate on 
this point.

I like the amount of kernel choice we have available, and contrary to your 
argument, I don't think it's confusing at all to the user. As long as the 
kernel guide on the Gentoo website is kept up to date, I don't see a problem 
here.

> -------------------------
> 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?

Are you telling me you install software more times than you load it? This 
argument is very weak. I agree that ebuilds beeping at me when I'm trying to 
update world gets on my wick a bit, but until another method for relaying 
important (and they are important) messages to the user, I guess it has to 
stay.

>  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.

Adressed this above.

> My requests:
>
> 1) Eliminate all use of sleep in ebuilds

Agreed. Although it's mildly annoying, I don't think it's a huge priority.

> 2) Eliminate all use of beeps via echo -ne "\a"

Agreed. Emerge is meant to be non-interactive, and if you leave the PC while 
you're updating world you will miss valuable message. The install shouldn't 
have to be monitored.

> 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.

Great, file a bug, attach the code and lets see about getting this into 
portage 2.1!

> 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.

On the other hand, as Gentoo is a distrobution for some of the more advanced 
linux goats, I think defaults should be set, and if you don't like it you can 
customise it. Gentoo has many users and can't please all of them.

> with sincere regards
> Dhruba Bandopadhyay

Cheers,
Chris.

-- 
            It is easier to fix Unix than to live with NT.


--
gentoo-dev@gentoo.org mailing list