Summary: | stage2 -> stage3: Portage wants to re-merge already installed packages | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Maik Schreiber <blizzy-keyword-gentoo_bugs2.a8a736> |
Component: | Unclassified | Assignee: | Gentoo Release Team <releng> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | blizzy-keyword-gentoo_bugs2.a8a736, drobbins, vapier |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Maik Schreiber
2002-07-23 13:42:37 UTC
i thought bootstrap works like this: install the last version of a package known to be 'stable' (thus bootstrap installs sys-libs/glibc-2.2.4) when you goto update the system, it will update glibc to 2.2.5-r7 (which is the latest out in the portage tree) purpose: to get a known stable base before going anywhere else yes ? nope. Just to verify -- you started with a stage1 image, bootstrapped, and then did emerge system right? Because if you started with a pre-made stage2 then it could want to upgrade some things for you. Yes, I've started with stage 1 and bootstrapped. Then when I did "emerge system" it wanted to re-merge already installed packages, like glibc (exactly the same ebuild version number). "emerge -u system" worked like one would expect for "emerge system" in that case. OK, problem found and fixed in 2.0.18 I've just bootstrapped a new 1.4_rc1 system, and this pops up again with Portage 2.0.37. Blizzy: Verify this one for me. Was it just the U/N flip flop, or is it still and issue? assigned/fixed borks the database,changing to resolved:fixed. //ZhEN |