[SM-Discuss] Going back to Gentoo

Kevin Monceaux Kevin at RawFedDogs.net
Wed Oct 29 10:32:52 EDT 2008


Source Mage Fans,

I've been chatting a bit both here and on IRC recently.  I didn't want to 
just "disappear without a trace."

After several recent battles with cleanse I finally took a couple of steps 
back and reevaluated what I like and dislike about SMGL and Gentoo.  And, 
well, there's more that I like than dislike about Gentoo.  If y'all would 
allow me to ramble just a bit about a few things I've noted along the way, 
maybe some of this will help to update the "Gentoo Differences" page, and 
some might even inspire an SMGL enhancement or two.  None of this is in 
any way, shape, or form intended to speak poorly of SMGL.  It's all 
intended as constructive criticism.  I think both distros have their 
strengths and weaknesses.

To be honest, one of the things that attracted me to SMGL is it's name and 
logo.  Source Mage sounds much more cool than Gentoo.  But, that's not 
really enough.  Until the recent layout change I also liked the look of 
SMGL's web site over Gentoo's.  No offense, but the current layout looks 
like a generic wiki site with an SMGL logo added at the top.

One clear advantage with Gentoo is the number of available packages.  A 
recent sync reports I have 13,025 packages in my portage tree.

On to the subject of speed - It was a couple of years or so ago when I got 
fed up with Gentoo and first tried SMGL.  At that time many portage 
operations were painfully slow.  I can remember an emerge --sync, roughly 
equivalent to SMGL's scribe update, taking a half hour or more to update 
the portage cache, and that was after it had downloaded all the updates. 
It got to where I hardly ever updated my box.  Sure, I could have set up a 
cron job to sync in the middle of the night, but I prefer to do such 
things interactively.  At that time SMGL had a clear speed advantage. 
But, I think the tables have turned.  After giving Gentoo a second chance 
recently I've discovered that portage's speed is vastly improved.  Now 
from start to finish an emerge --sync takes about a minute or three. 
And, since I use eix, I also get a nice colorful summary afterwords 
listing package updates, and highlighting the version if the package is 
currently installed, not to mention a list of new packages, etc.  For 
example, here's the last two lines of summary info from the sync I just 
ran:

[*>]  == x11-drivers/xf86-video-virtualbox (~1.6.6 ~2.0.2 ~2.0.4 -> 1.6.6):
VirtualBox video driver
[N]   >> app-portage/porticron (~0.1): porticron is a cron script to sync 
portage and send update mails to root

Sorry for the lack of color and mangled formatting.  One can only do so 
much with plain text e-mail.  It's easier to interpret with the colorized 
output.  The first line shows that version 1.6.6 of xf86-video-virtualbox 
has been unmasked.  In other words, that version is now considered stable. 
The last line shows that porticron has been added as a new package.  With 
the above sync run there were no updates for any installed packages on my 
box.  But, if there were the summary would tell me.

On a similar note, portage searches are also much faster now days. 
Unless something is bogging down the system, search results start flying 
by almost as soon as I hit the enter key.  And, I like the colorized 
output and amount of information they show.  For example, if I:

# emerge --search vim

the listing for vim itself would be:

*  app-editors/vim
       Latest version available: 7.2
       Latest version installed: 7.2
       Size of files: 9,077 kB
       Homepage:      http://www.vim.org/
       Description:   Vim, an improved vi-style text editor
       License:       vim

which shows lots of info all summarized in one place.  Or, with eix vim:

[I] app-editors/vim
      Available versions:  7.0.235 7.1.123 7.2 ~7.2.021 {acl bash-completion cscope gpm minimal nls perl python ruby vim-pager 
vim-with-x}
      Installed versions:  7.2(06:58:04 PM 10/27/2008)(acl gpm nls perl python ruby -bash-completion -cscope -minimal -vim-pager -vim-with-x)
      Homepage:            http://www.vim.org/
      Description:         Vim, an improved vi-style text editor

which shows it's available use flags, the use flags it was installed with, 
etc.  eix is a portage search utility that was created back when portage 
itself was so painfully slow.  Now emerge --search speed is comparable to 
eix, but eix still has a few nifty features which makes it worth keeping. 
I mainly use eix for searching.  I've omitted several other search results 
from the above.  With eix there's also a "compact" listing option which 
works well when a search returns lots of results.  A few results from
eix -c vim:

[N] app-editors/gvim (7.2): GUI version of the Vim text editor
[I] app-editors/vim (7.2 at 10/27/2008): Vim, an improved vi-style text editor
[I] app-editors/vim-core (7.2 at 10/27/2008): vim and gvim shared files

Again, it looks better with color.  It highlights versions that are 
installed, and even shows the date they were installed From the above, I 
can tell at a glance that gvim isn't installed while vim and vim-core are.

It seems with gaze I have to ask for each bit of info available for a 
spell separately.  Although I did manage to get a little more information 
when searching with something like:

# gaze version `gaze -q search -name vim`

I do like the long descriptions available on SMGL.  Gentoo appears to only 
have short descriptions.

Another area where speed is concerned - revdep-rebuild versus cleanse: 
With a little over 300 packages on my SMGL box a cleanse run took well 
over an hour.  I just ran a revdep-rebuild on my Gentoo box with 494 
installed packages.  Total time was 2:06.17.  That's two minutes, not 
hours.  Now that might not be a fair comparison.  I'm not sure exactly 
what's going on under the hood but I suspect cleanse is performing a much 
more thorough check, sometimes too thorough.  Did I mention my recent 
battles with cleanse above?

On to configuration file updates - How are configuration file updates 
handled in SMGL?  Several man pages say to see confmeld.  I viewed the 
confmeld man page but never found any updated files where the man page 
said they should be.  I did, however, see the occasional message while 
casting a spell asking me how I wanted to handle a config file update.  Of 
course, if the cast was running unattended, it would time out and take the 
default response without me seeing the message.  On Gentoo after a merge 
it displays the number of config files that need updating, if there are 
any.  If there are any, I can use dispatch-conf to take care of the 
updates.

On to the subject of USE flags versus playing 297,586 questions.  The 
first time around using Gentoo I hated USE flags.  After trying some other 
distros, I've come to realize USE flags can be a good thing.  Combined 
with emerge's pretend feature one can get things set they way he/she 
wants, then start the emerge and walk away.  For example, if I were about 
to install vim I could run an emerge -pv vim, which would list vim and all 
the dependencies that would be installed, along with all their use flags. 
In the case of vim, I have the X USE flag set globally on my system but I 
just want plain vim.  So, after running the pretend emerge for vim I 
realized that and disabled the X USE flag for vim itself.  I ran one more 
pretend emerge to make sure all was to my liking, then started the real 
emerge and went on to doing other things while it ran.

Another plus to USE flags - I'm on my third recent Gentoo install.  I 
saved copies of my /etc/make.conf and /etc/portage/package.{keywords,use} 
files from the first time around.  On the second and third installs I 
could just install everything and all my USE flag preferences were already 
set.

I see two drawbacks to SMGL's question/answer sessions.  If I respond to a 
question and realize right after responding to it that I should have 
answered differently, I have to cancel and start over.  Also, for most 
questions timing out and taking the default answer makes sense.  For some, 
it doesn't.  For example, while I was casting openoffice-bin it wanted 
some form of Java.  I picked one and was told that I needed to download 
the file manually.  While I was doing so, the prompt asking if I had 
downloaded the file timed out and the cast continued and failed because I 
hadn't finished downloading the file it wanted yet.  Those type of 
questions should not time out.

On to logging - SMGL does a much better job of handling compile logs, etc. 
than Gentoo does.  Back when I first used Gentoo, it didn't even save 
compile logs.  Now with it's new elog system one can save various logging 
info.  But, I haven't found a utility that cleans out old log files like 
cleanse does.  One nice Gentoo log parser is genlop.  It can do several 
nifty things.  If an emege is running genlop -c will show which step it's 
on and if it's something that's been merged before it will even give an 
eta.  On a previous Gentoo install I captured the following output while 
merging openoffice:

Currently merging 11 out of 11

  * app-office/openoffice-2.4.1

        current merge time: 6 hours, 24 minutes and 10 seconds.
        ETA: unknown.

After it finished the merge, genlop -t openoffice would show the total 
time:

  * app-office/openoffice

      Thu Sep 25 18:46:01 2008 >>> app-office/openoffice-2.4.1
        merge time: 6 hours, 35 minutes and 5 seconds.

This time around I went with openoffice-bin.  Genlop can also take the 
output from an emege --pretend run and give an eta if everything in 
question has been merged before, such as when performing the Gentoo 
equivalent of a system-update:

# emerge -pu world | genlop --pretend

Sorry, I don't have any example output for the above and everything on my 
box is up to date at the moment.

Okay, I think I've rambled long enough.  I'll continue to follow the SMGL 
mailing lists but I think for now Gentoo is the better fit for me 
personally.


Kevin
http://www.RawFedDogs.net
http://www.WacoAgilityGroup.org
Bruceville, TX

Si hoc legere scis nimium eruditionis habes.
Longum iter est per praecepta, breve et efficax per exempla!!!



More information about the SM-Discuss mailing list