[ale] Gentoo: the good, the bad, the ugly

Charles Marcus CharlesM at Media-Brokers.com
Mon Aug 26 10:18:51 EDT 2002


> From: Bill Sirinek [mailto:bill at sirinek.com]
> Sent: Sunday, August 25, 2002 6:13 PM
>
> I'm going back to Debian as soon as they get KDE3 rolled
> into sid. Gentoo is a pain (I dont care about building
> from source)

I take it, by pain, you mean the time it takes to d/l, configure and compile
every package?  This is too true, and if you don't want/care about
installing from source, completely understandable...

> and while its portage system is nice, I like apt a lot
> better.

Just curious... can you be more specific about what apt does better than
Portage?

> Debian does a lot better job with configuration and making
> sure their packages all work too.

This is definitely a problem with Gentoo, but one that comes with the
territory of being on the bleeding edge.  It's really not a problem as long
as you don't install the latest/greatest the day it comes out.  I always
give new packages a week or two, to see if anyone is having problems with
it.

One thing, though - the changes and upgrades to Portage itself can
especially be a real problem - one inherent to how new Gentoo really is.

Hopefully, within the next 6 mos to a year, Portage will mature, and become
very stable, after the major changes (full reverse dependancy checking is
one they are currently working on) are all completed and it stops being such
a fast moving target.  But as I said, as long as you are careful not to
upgrade Portage itself until you are sure the new version is working
properly, and don't upgrade packages on a daily basis, you should be fine.

> On Sunday 25 August 2002 17:05, Byron A Jeff wrote:

<snip>

>> The Bad
>> -------
>> * Well there can be too much of a good thing. I'm a firm
>> believer of the layered abstraction model where every layer
>> of abstraction is provided and you pick the one of your
>> comfort level. Well the Gentoo install pretty much poured
>> acid on that model and melted everything back to the base
>> layer. While none of the installation process is particularly
>> difficult, it would be so much simpler if there was a simple
>> script that guided the install and issued the commands for
>> you. Not necessarily at the highly abstracted level of a
>> RedHat install, but something akin to Slackware's install
>> scripts which helps you along without hiding what's going on
>> underneath.

There has been a bit of discussion in this regard, and I am sure that sooner
or later someone will write some automation scripts.  There was even talk of
a basic GUI installer, but the Gentoo developers were adament that the
command line install would always be there for those who want absolute
control over every aspect of their installation - in other words, the goal
is to have the best of both worlds.

>> * Along those same lines I think that there needs to be an
>> further extension to the staging process where a base
>> workstation can be dropped in. Or where groups of packages
>> could be choosen for compilation. There doesn't seem to be
>> an easy way to browse and select packages available in
>> the Portage system. Though as I pointed out in the Good
>> section, once you pick a package, it's ready to go after
>> the emerge command.

There is a KDE app call kportagemaster that has been reported (I haven't
used it yet) to be very useful, and provides this functionality - you might
wanna check it out.

>> The same is needed for the rc-update process: a list of
>> what's active and a list of what's available.

I couldn't agree more.  This is a major shortcoming that I hope is being
addressed - in fact, I will post this question to the list (I've meant to in
the past, but forgot).

>> The Ugly
>> --------
>> * No KDE man! emerge craps out on arts. Now mind you
>> that I have -arts in my USE variable in /etc/make.conf.
>> Mind you that I did an emerge rsync to get the latest
>> tree. Mind you that I really can do completely without
>> sound at the present time (as I don't have a sound card
>> installed). But it's preventing the compilation of the
>> rest of the KDE package.

Just saw something on the list that *might* apply (he wasn't specific on the
error he was getting):

"The only snag I ran into during recompile was with KDE
packages. The packages seem to include their own compiler
optimization settings, including -O2. In my particular
case, including any -Ox setting at all in /etc/make.conf
caused KDE3.0.3 builds to fail. Removing this allowed
the packages to compile just fine. I put it back when
they were finished and rebuilt the rest of the packages."

Regardless, this is not normally a problem - I've installed KDe at least 15
times, and never had a problem like this.

Charles


---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be 
sent to listmaster at ale dot org.






More information about the Ale mailing list