Gentoo (was: ARTICLE - ESR gives up on Fedora)

Dan Miller rambi.dev at gmail.com
Mon Feb 26 20:35:02 EST 2007


> On 2/26/07, Bill Mullen <moon at lunarhub.com> wrote:
>>> suggested in the past that something like a cross between BSD ports
>> > and RPM might be a good solution for many problems.  Something that,
>> > with one simple command, could automatically download all the needed
>> > source packages, configure, build, and install them, without scary
>> > looking terminal windows or the need to edit configuration files by
>> > hand.

Whats scarier? vim /etc/config_file.config or kate 
/etc/config_file.config? Its not that scary, you don't need to edit many 
many config files. Most of the stuff is set with good defaults.

>>
>> Sounds like Gentoo's "Portage" system, accessible either via the CLI 
>> or by way of
>> any of a number of GUI frontends, would appeal to you:
> 
>  I just *knew* someone was going to reply with "Portage".  :)
> 
>  I was interested in Portage when I first heard about it.  Still am,
> in the sense that I'm a geek and like try to different things.  But
> every single Gentoo user I've ever encountered states that editing
> config files and running things from scary-looking terminal windows is
> pretty much a given on that distribution.  No problem for me, but it
> pretty much kills it for the PDOTLREBTWWLLAPACTT[1] crowd.  Maybe I've
> just been talking to the wrong Gentoo users; I dunno.

Its not that scary. I've automated most commands I do. I have a nightly 
cron that syncs the portage, then runs emerge -upD world (check 
everything in my world file and its dependicies to see if there are any 
updates). The output of this and glsa-check -tv all (check to see if any 
install packages have security issues). The output of these are then 
emailed to me every morning. I also have a logwatch report that comes to me.

I open up the CLI to run emerge, ssh, and various other commands. The 
CLI is faster in some ways than any gui.

> 
> [1] People doing ordinary tasks, like reading email, browsing the web,
> writing letters, looking at pictures, and calculating their taxes.
> 
>  Gentoo also appeals to me because Gentoo users aren't constantly
> harping about how perfect Gentoo is.  ;-)

Yep! ;-)

> 
>> Slower, definitely, but on recent equipment sporting dual-core CPUs 
>> and acres of RAM,
>> it's not as pokey as one might expect it to be.
> 
>  Build GNOME or KDE from source, and let me know how long it takes.  ;-)

Emerging OpenOffice took me about 3 hours, thats on a dual-core dual 
proc Opteron 2800SE with 4 gigs of ram.


> 
>> Gentoo also has prebuilt packages available for many apps ...

openoffice-bin, firefox-bin, mozilla-sunbird-bin just to name a few.

> 
>  Okay.  I'm sure that is great for Gentoo and Gentoo users.  But
> doesn't that kind of defeat the whole "building everything from
> source" idea?

Sometimes the binaries hit the portage before the sources do. If 
building on a slow machine, you might not get that much of a benefit 
building from source, so the binary would work just fine.

> 
>> You could install something like GNOME prebuilt and then recompile it 
>> in the
>> background for your specific system's configuration ...
> 
>  Now *that's* a neat idea.

I think thats emerge -k. Its recommended to do that with alsa.

> 
>> When reporting a bug with an ebuild, one merely also includes the USE 
>> flags that are in
>> use on the system having the problem, and that's usually sufficient to 
>> account for these
>> sorts of variations.

The use flags determine what libraries the app is built against. Say I 
want thunderbird, but don't want ldap. I leave the ldap library out, and 
thunderbird won't have that feature. If I want it, then put that in the 
use flags, and rebuild. Thats the meaning of the use flags.

> 
>  The problem with that approach is that (1) most software is barely
> tested at all, and (2) when it is tested, the testing usually consists
> of running unit tests against various possible SCM scenarios.  (This
> is a fancy way of saying the developer installs it on a couple
> different computers.)  When building everything from source like that,
> the number of SCM scenarios approaches infinity.

In the ebuild, you can specify what it relies on. But yes it can.

> 
>  Plus, say I mail the package maintainer, and he looks at my "USE
> flags", and he says, "Huh.  Not sure what your problem is, but your
> system is completely different from my system."  One of us is going to
> have to drastically change our build environments to debug the issue,
> no?

Thats the maintainers problem, not yours. He should change, but if he 
says this use flag will fix it, then thats usually all you have to do.

> 
>> Going back to ESR's beefs, Portage is also not immune to the 
>> occasional problem with
>> dependencies ...

Thats why there is revdep-rebuild. it double checks what you have 
installed, what is needed and rebuilds that libraries that it needs.

> 
>  I find most dependency problems fall into one of four categories:
> 
> (1) Normal dependency.  A needs B and C.  Tools like apt-get and yum 
> solve this.
> (2) Package maintainer screwed up the dependency definitions.  GIGO.
> (3) Building environment differs from install environment; package
> manger properly refuses to install potentially incompatible package;
> user is frustrated.
> (4) Building environment differs from install environment; package
> manger properly refuses to install potentially incompatible package;
> user overrides package manager; system starts to fall apart.

Portage solves that same issues that apt-get and yum do, they just give 
the user more control. Say you want to emerge kde on a fresh gentoo 
install. Emerge will see that you need X, qt, kde-libs, and all the 
other libraries. The optional things come in then. If you want cervisa 
(or whatever that is called) then you add the use flags. If you are 
installing distcc, but don't want X, then you add a -X to the use flags 
and it won't install distccmon-gnome.

> 
>  The second category certainly plays a role -- sometimes a big one.
> People make mistakes; that's a given.  As most package maintainers are
> people, it follows that packages will sometimes have bogus dependency
> information, and that can quickly cascade to Big Trouble if it's a key
> package.

I've seen it a few times. Just wait awhile (a week or so) and it should 
be fixed. You don't have to update the packages daily.

> 
>> ... it has a few powerful features (such as slots, arch keywords and 
>> package masking)
> 
>  Ohh, now those sound interesting.  I have no idea what they are, but
> they sound interesting.  :-)

Slots are where you can have the same thing installed as different 
versions. Gentoo-sources, automake are the biggest that run with slots 
that I've noticed.

Arch keywords are where I can take a "beta" package and tell my system 
to use this instead of the stable. This can be useful if you want to run 
Beryl (still masked) but can break a system sometimes. You need to be 
picky and not run the full system in the keyword mode. That will break 
many things. (I've done it)

Masking is where you tell portage not to use or mask that version. This 
is rarely done, except in the beta packages. I've had to set a few where 
the application breaks things, but its been awhile since I've done that.

> 
>  Would you be interested in giving a LUG presentation on Gentoo,
> Portage,  emerge, etc?  Or have you already, and I just missed it?  :)

Wow, there is a lot in portage, and the emerge process has, about the 
only thing that can be done is a nice overview. With some of the 
benefits, and power a user has.

There is even much more to the portage that what is address here.

Dan
> 
> -- Ben
> _______________________________________________
> gnhlug-discuss mailing list
> gnhlug-discuss at mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
> 


More information about the gnhlug-discuss mailing list