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

[Byron A Jeff]

[snip Gentoo vs. Debian]
> >> 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.

Which is of course the goal I alluded to above.

> 
> >> * 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).

It's not that big a deal. I mean literally an 'ls /etc/runlevels/boot' is
sufficient to show what's going to happen and an 'ls /etc/init.d' is enough
to show what's available. I am however extremely curious about how rc script
dependancies are managed.

> 
> >> 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.

It's just saying that arts-1.0.3 isn't found on ibiblio.com. There's a 1.0.2
and 1.0.6. In the portage tree there's 1.0.2,1.0.3, and 1.0.7. So there's a
sequencing problem. But the interesting thing is that my '-arts' in my USE
line in /etc/make.conf should skip it completely. That's why I'm really annoyed.

BAJ

---
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.