Attn: robbat2, not bbullock, sorry -- Gentoo questions

[unixronin]

So here I am, finally getting around to installing Gentoo on an extra disk in babylon5, with the intention of migrating over to it altogether once I get it set up how I want.  Right now, I'm still running my Gentoo environment chrooted under my 2.4.31 kernel, until I have it fully set up.  Only, so far I'm running into a few setup problems I can't find answers to.

• I can get emerge to build Perl with ithreads enabled by placing 'dev-lang/perl ithreads' in /etc/portage/package.use.  I cannot get it to build Perl with ithreads, use64bitint, and uselongdouble enabled; it ignores all my attempts to do so.  How do I make it play nice in this regard, and keep doing so?
• Every time I emerge a package, it gives me a list of dependencies it will install.  Among this list, invariably it tells me that before proceeding, I should update portage to sys-apps/portage-2.0.51.22-r3 before proceeding, and that I can accomplish this by emerge -u portage.  When I then execute emerge -u portage, it tells me portage is up to date and there's nothing to do.  What's with this?
• All the documentation seems to indicate that udev, unlike devfs, offers no mechanism to address a device as (for example) /dev/sd/c1b0t5u0p4 instead of /dev/sdd4.  I hate and despise the /dev/sdx model; it's horribly broken, it's lame, and every time you insert a device, you have to figure out which other device identifiers are now going to point to different devices than they used to.  (I am in fact totally gobsmacked that, by kernel 2.6.14, Linux still uses the /dev/sdx model at all, even for legacy support.  I repeat and emphasize, it's HORRIBLY BROKEN and should be considered harmful.)  Is there any means that the Gentoo installation handbook just isn't bothering to tell me about, by which I can tell udev to use fully specified device identifiers that I can safely rely on to always point to the same physical device?

Comments

[tww1fa]

For the perl stuff you may need to create your own ebuild. Set PORTDIR_OVERLAY=/usr/local/portage in your make.conf, mkdir -p /usr/local/portage/dev-lang/perl, cp -r /usr/portage/dev-lang/perl/* /usr/local/portage/dev-lang/perl, then edit the .ebuild in /usr/local/portage for the version you want to use (5.8.6-r8 seems to be the latest,) then run "ebuild perl-5.8.6-r8.ebuild digest" to rebuild the digest, and emerge again.

For the portage stuff, make sure you've run etc-update or dispatch-conf after the portage update - otherwise it may not be able to detect you're using the new portage.

You can tell udev to use devfs type names - in fact in /etc/udev/scripts there are scripts you can call from your rules file to do just that. You'll have to update your udev rules to use those scripts, however the default rules already provide fixed names for your disks - take a look at /dev/disk/by-* which are populated by symlinks pointing to the canonical device names. Personally, I mount by partition label so the naming scheme doesn't affect me except when I'm partitioning.

[unixronin.livejournal.com]

Maybe I'm just not going to be able to get all of this working until I can boot from it. Getting it bootable without some of this stuff working may be entertaining. :p

[midiamin.livejournal.com]

To clarify, the reason you may have to create your own ebuild is because use64bitint and uselongdouble are not known to the portage tree. Reading from /usr/portage/dev-lang/perl/perl-5.8.6-r7.ebuild:

IUSE="berkdb debug doc gdbm ithreads perlsuid build minimal"

Since your extra flags aren't known to the perl ebuild, it ignores them and won't pass appropriate flags to configure. Naturally, maintaining your own perl ebuild could be a pita as time goes by, so you might lobby the maintainers for a new use flag or other workaround. Until then, don't forget to pin perl to the version you have a custom ebuild for lest the system try to replace it with a non-hacked version when a newer version becomes available.

And I second what he says about udev rules.