Skip to Content.
Sympa Menu

sm-discuss - [SM-Discuss] Going back to Gentoo

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Kevin Monceaux <Kevin AT RawFedDogs.net>
  • To: SourceMage Discuss Mailing List <SM-Discuss AT Lists.IBiblio.org>
  • Subject: [SM-Discuss] Going back to Gentoo
  • Date: Wed, 29 Oct 2008 09:32:52 -0500 (CDT)

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@10/27/2008): Vim, an improved vi-style text editor
[I] app-editors/vim-core (7.2@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!!!





Archive powered by MHonArc 2.6.24.

Top of Page