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

["Robin H. Johnson" <robbat2@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 7226 bytes --]

On Mon, Nov 03, 2003 at 01:29:19AM +0000, Dhruba Bandopadhyay wrote:
> --------------------------------
> Scenario 1: slocate and updatedb
> --------------------------------
[snip]
> 1) Remove slocate from base system
> 2) Remove makewhatis from daily cron duties
> 3) Remove updatedb from daily cron duties

Items 2 and 3 above are easily accomplished with 
chmod -x /etc/cron.daily/{makewhatis.cron,slocate}
That's all that's needed.

> 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.
The big issue at hand isn't pleasing just you, but finding the best
common ground for all Gentoo users. Based on what I know of UNIX users,
I'd say more often than not they want and use the the locate command
(which is provided by slocate).

You note that you are interested in the enforcement of 'expected vanilla
behaviors' of the operating system.

Vanilla is defined as:
"Lacking adornments or special features; basic or ordinary"
(Dictionary.com)

> 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. 
I haven't seen a single UNIX other there (apart from LFS and it's kin)
where some form of regularly running updatedb/makewhatis isn't present
by default. 

Therefore, it logically follows that it is ordinary and vanilla to have
slocate and makewhatis in place.

I will concede one point with regard to them, running them as 'niced' as
possible is probably a worthwhile change to make so that they don't hit
our systems so hard.

Consider also tweaking what time the daily cronjobs etc. run, so that
they take place at a time your computer is up and running, but you
aren't actively using it.

> -------------------------------------
> Scenario 2: baselayout and /etc/issue
> -------------------------------------
[snip]
Again, see my comments about what is vanilla.

> My requests:
> 1) Eliminate /etc/issue and rename it if it must be added to the system
Somewhere, I recall seeing a package that required /etc/issue to exist,
as it caused problems otherwise.

> ---------------------------------------------------
> Scenario 3: vanilla kernels and development sources
> ---------------------------------------------------
> -------------------------------------
> scenario 4: kernel sources on portage
> -------------------------------------
[snip]
I'm not going to argue about kernel stuff, other than to say that there
should be an absolute minimal amount of modification compared to how
each set of sources ship. Please note that is not only vanilla sources,
but rather all sources in the tree. 

> 1) Create gentoo patchsets only for finished releases and separate into 
> different sources
In the case of the custom gentoo kernels, they are shipping with plenty
of customizations of their own, because they intend to have them.

> 2) Provide vanilla kernels as unaltered, unpatched and uncustomised sources 
> just as they would be if done manually
Acceptable changes should be fixes of major breakages and compilation
fixes specific to the Gentoo system. GCC3.3 string fixes for a major example.

> 3) Agree on prerequisites that must be fulfilled prior to adding new 
> kernels-sources or in fact any new packages onto portage.
Define pre-requisites in this case. I'd say any commonly used and
expected kernel for all architectures that Gentoo supports and is in the
process of trying to support belong in the tree.

> -------------------------
> Scenario 5: Ebuild speech
> -------------------------
[snip]
The beeps and waiting are there for a specific reason, in that sometimes
there are very important messages that WILL break a users system unless
they do some additional instruction that is specified. We generally try
very hard to avoid this, but there are some cases where it cannot be
avoided. 

For an example, I'm currently writing up some ebuilds for the new 5.3
tree of vpopmail, because it will be released from it's upstream beta
state soon. The upgrade path involved in this, if I were to have a
script to do it automatically, would entail forcing the user to stop
courier-imap+qmail, run the emerge upgrade, run a command to migrate
their data, and recompile courier-imap, and restart qmail+courier-imap.
So now, how to go about this and NOT break the system of the user that
runs 'emerge -u world' and goes to bed? There is no simple solution for
this.

> 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. 
The big problem is quite simply that users don't read the big warnings
and information as it stands already. The beeps and sleeping at least
get a fair number of users to read the messages and find out what to do.
However I still get a significent number of bugs filed just because
users fail to read the instructions that have been provided.

One that keeps getting filed as a bug with some regularity is the mysql
configuration instructions to create the database and set the initial
passwords. Absolutely essential for the application to work, and
completely documented in the pkg_postinst of the package telling you to
run the ebuild ... config command. Yet I still get several bugs a month
for this, because users failed to read the instructions that we
provided.

If there were a solution that could resolve the issues you have with the
delays and waiting, while still getting more of the users to READ the
instructions that are already provided, I'd be incredibly grateful as it
would reduce the amount of time I spend on non-productive bugs. For each
of the bugs that gets filed presently like this, I try as hard as I can
to ensure that the user understands the problem and is explictly shown
how to resolve it.

> 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.
Logging is already done, see PORT_LOGDIR in make.conf. If you really
need to find the messages afterwards, just grep in the newly produced
logfiles as you do above.

> 1) Eliminate all use of sleep in ebuilds
> 2) Eliminate all use of beeps via echo -ne "\a"
> 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
No arguments with this in principle. Lets have FEATURES="sound" and
FEATURES="wait", both enabled by default.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]