Access Violations
First was the dreaded "ACCESS VIOLATION SUMMARY" error. Portage builds packages inside a virtual sandbox, and uses it to ensure that ebuilds don't do anything bad.
That said, sometimes not-fully-tested ebuilds get into the portage tree and make life a little more complicated.
The right thing to do would be to file a bug-report, with details related to you environment, packages, etc. etc. But then, some of us just want to get things done a little quicker.
$ FEATURES="-sandbox" emerge application
The above command temporarily disables the sandbox during the emerge. Do NOT do this with emerge world, as at that point, you'll just be testing fate.
What you need to do is, first proceed with a normal emerge. Go through the logs and find out why exactly the access-violations occured (chmod, unlink etc.) If you're comfortable with what you see then disable the sandbox for the broken application only.
Masking Packages
Portage also tried to upgrade postgres from v7 to v8. No no. This won't do.
This means that I would need v8 bindings for ruby, perl and python. Not to mention framework support for things like rails and twisted.
Not going there.
The solution to this is really quite simple. Add the following line to /etc/portage/package.mask.
>dev-db/postgresql-8.0.0
No DevFS
As close to the metal as Gentoo is, sometimes it does try and get ahead of itself. Like automatic /dev management detection. Within /etc/conf.d/rc, there's a new option called RC_DEVICES. It's set to "auto". This means that it tries to automatically detect if you're using devfs, udev or static device links.
My kernel was compled with devfs support, but I wasn't using it. Gentoo detected it and assumed that devfs was my preference. Ugh.
Now I had a system that wouldn't boot. You can imagine what it was like trying to figure this out.
Anyhow, to get out of this mess you need to rebuild the kernel without DevFS support.
Bummer.
The Lesson
Do _NOT_ use "emerge world". Instead, use "emerge -pv world", find the packages that need to be upgraded, and emerge them individually.
Always use "-pv" to verify what portage is going to do before the real emerge.
I learned this lesson a long time ago.
ReplyDeleteNever never never never never never never do an emerge before an "emerge -pv".
Theres money in that one.
emerge -avt is really nice too..
ReplyDeletea means ask, so instead of calculating the deps, then having to recalculate them once you've decided you want to emerge a package, you can choose yes or no.
v is verbose
t makes the deps into a tree so you can see exactly why other packages might be installed
I definitely use -a over -p\
ReplyDeletereally no reason to use -p, except as a non-root user just to query the emerge database without wanting to do anything. as jason says, -a shows the exact same info.
another point I'd like to add. I would never use
FEATURES="-sandbox"
everytime I ran into a sandboxing error, I just try to workaround it or fix it by modifying the .ebuild file.