This is the second person. Earlier it was Mandu. Who said that it was fun but it took too much it and that he doesn’t want to spend too much of the precious resource – time.
Yesterday, ManuBansal posts on iitk.questions.unix:
Manu Bansal wrote:
> Another Gentoo loyal turned away.
>
> All I wanted to do was to upgrade to Valknut-3.8 from 3.7. dclib won't
> compile, and I wouldn't know why. Nobody would know why. Then suddenly,
> working on a project one day, it would occur to me that probably new code
> wouldn't compile with my relatively old gcc. And I would decide to upgrade
> gcc. I wouldn't know why the system is not using the newer gcc, and then,
> not being that noob, I would unmerge the old gcc, in the hope that the new
> gcc would come in effect. It still wouldn't, so I would update environment
> etc, but that wouldn't help either. And then I would take the plunge,
> without knowing that I was about to, and reboot. And nothing would work
> anymore! All applications would bail out for missing glibc. So I would
> realize I've lost glibc, and apps were compiled against the old one. So I
> would again try to emerge the old one, and even python would complain for
> the lib! Wow! That IS stranded. Then, and only then, would I get to know
> that there's a full Gentoo gcc upgrade guide.
>
> That I was able to put back my system did have a good effect - it raised
> my confidence in my hack-debug-skills. But then what would I do?
> An "emerge -eav system" and then "emerge -eav world". And then I will
> realize ebuilds for half of my packages don't exist anymore!
>
> I'm still not saying Gentoo package management is bad. But is it useful at
> all? A system which CAN benefit from compile optimization benefits would
> die compiling packages before they can be used. A system that can compile
> fast doesn't need those optimizations. And even the never-beatable
> dependency management goes for a ride when you upgrade 200 packages (half
> of them being kde) at a go. And gcc upgrade remains dirty - all it has is
> some suite of grep-based scripts, in addition to usual emerge.
>
> If one has still to upgrade all 100-200 packages, wouldn't bins/rpms be
> better?
>
> "Murphy's Law of Gentoo installation: If a compile can fail, it will."
> -- source: http://forums.gentoo.org/viewtopic-t-322136.html
>
> What is it called? Ubuntu? Or Fedora? ...
>
> Manu.
And you know what? I forgot to mention the funniest idea they have in
emerge - once in a while, a package emerge would beep for 10 seconds,
trying to draw your attention to a super-important message about a followup
action to the installation, maybe even something like "follow the gcc
upgrade guide". And that will happen in a compile of 4 hours on a P4 with
abundant RAM, after which the compile will spit enough to drive out the
message from display cache. Do they expect us to sit and stare at the
compile all this while?
All this leaves me wondering. Was he so out of touch after all? Looking at the need to upgrade his gcc for the valknut upgrade, it hints that he hadn’t updated his system in a long-time. And that too, long enough not to realize that there’s a proper way to upgrade his gcc. He unmerged his gcc! At least, he could’ve unmerged it with the = and version number…
emerge -Cav =sys-devel/gcc-3.4.6-r4
(assuming that 3.4.6-r4 was the old version he was trying to get rid of). It still is a mystery why he had to do that when he could’ve googled to figure out that there’s a handy tool called gcc-config.
Disheartening.
About the info warn qa messages – he should’ve made use of the ELOG system the recent versions of portage come with.
Here’s a snip of the /etc/make.conf.example
# logging related variables:
# PORTAGE_ELOG_CLASSES: selects messages to be logged, possible values are:
# info, warn, error, log, qa
# Warning: commenting this will disable elog
PORTAGE_ELOG_CLASSES="warn error log"
# PORTAGE_ELOG_SYSTEM: selects the module(s) to process the log messages. Modules
# included in portage are (empty means logging is disabled):
# save (saves one log per package in $PORT_LOGDIR/elog,
# /var/log/portage/elog if $PORT_LOGDIR is unset)
# custom (passes all messages to $PORTAGE_ELOG_COMMAND)
# syslog (sends all messages to syslog)
# mail (send all messages to the mailserver defined
# in $PORTAGE_ELOG_MAILURI)
# save_summary (like "save" but merges all messages
# in $PORT_LOGDIR/elog/summary.log,
# /var/log/portage/elog/summary.log if
# $PORT_LOGDIR is unset)
# mail_summary (like "mail" but sends all messages in
# a single mail when emerge exits)
# To use elog you should enable at least one module
#PORTAGE_ELOG_SYSTEM="save mail"
# PORTAGE_ELOG_COMMAND: only used with the "custom" logging module. Specifies a command
# to process log messages. Two variables are expanded:
# ${PACKAGE} - expands to the cpv entry of the processed
# package (see $PVR in ebuild(5))
# ${LOGFILE} - absolute path to the logfile
# Both variables have to be quoted with single quotes
#PORTAGE_ELOG_COMMAND="/path/to/logprocessor -p '\${PACKAGE}' -f '\${LOGFILE}'"
# PORTAGE_ELOG_MAILURI: this variable holds all important settings for the mail
# module. In most cases listing the recipient address and
# the receiving mailserver should be sufficient, but you can
# also use advanced settings like authentication or TLS. The
# full syntax is:
# address [[user:passwd@]mailserver[:port]]
# where
# address: recipient address
# user: username for smtp auth (defaults to none)
# passwd: password for smtp auth (defaults to none)
# mailserver: smtp server that should be used to deliver the mail (defaults to localhost)
# alternatively this can also be a the path to a sendmail binary if you don't want to use smtp
# port: port to use on the given smtp server (defaults to 25, values > 100000 indicate that starttls should be used on (port-100000))
# Examples:
#PORTAGE_ELOG_MAILURI="root@localhost localhost" (this is also the default setting)
#PORTAGE_ELOG_MAILURI="user@some.domain mail.some.domain" (sends mails to user@some.domain using the mailserver mail.some.domain)
#PORTAGE_ELOG_MAILURI="user@some.domain user:secret@mail.some.domain:100465" (this is left uncommented as a reader exercise ;)
# PORTAGE_ELOG_MAILFROM: you can set the from-address of logmails with this variable,
# if unset mails are sent by "portage" (this default may fail
# in some environments).
#PORTAGE_ELOG_MAILFROM="portage@some.domain"
# PORTAGE_ELOG_MAILSUBJECT: template string to be used as subject for logmails. The following
# variables are expanded:
# ${PACKAGE} - see description of PORTAGE_ELOG_COMMAND
# ${HOST} - FQDN of the host portage is running on
#PORTAGE_ELOG_MAILSUBJECT="package \${PACKAGE} merged on \${HOST} with notice"
It was all there. Gentoo might not be just about optimizations. There’s unlimited scope for flexibility here. A little reading up saves a hell lot of headache later. And, why do you have to read so much? Because, probably, it was your choice to use Gentoo in the first place – and Gentoo doesn’t come to you as a desktop-distribution but as a meta-distribution. Do the initial setup well and live happily ever after.