Re: [gentoo-catalyst] [PATCH 1/2] Fix update_seed use by not using nor building binary packages during the seed update.

[Brian Dolbec]

On Tue, 2013-05-28 at 14:50 -0400, Rick "Zero_Chaos" Farina wrote:
> On 05/28/2013 01:59 PM, Brian Dolbec wrote:

> > Existing gcc binpkgs have been linked to libmpc.so.2 and portage does
> > not check that all lib links exist before qualifying the binpkg to be
> > installed.  Therefore installing a gcc binpkg is a hit and miss
> > proposition.  Making it's use un-reliable.  Therefore until the
> > toolchain is migrated to eapi 5 with proper subslot use.  Using binpkgs
> > is unreliable for update_seed.
>
> In fact, the command is "--rebuild-if-new-ver" not
> "--reinstall-if-new-ver".  As such, the original reporter of this bug
> and I both seem to think that even with --usepkg, gcc should be rebuilt:
>
> https://bugs.gentoo.org/show_bug.cgi?id=461422
>
> That's obviously not how it is, but I feel we should focus our attention
> on fixing this properly.
> >

I think you did a typo there.  There are 2 portage options
--rebuild-if-new-ver and --rebuild-if-new-rev.  I opted for the *-ver
(version), since most revisions would not need to trigger a rebuild.
But the failure in that bug should be the same or similar fix to our
needs.

> As a rule, we don't want to hack around limitations in portage to make
> catalyst work.  The toolchain team seems to have made it very clear they
> aren't updating to eapi5 soon, but the portage team has been fixing
> things left and right based on little more than my whims, I'd give them
> a chance to fix this before throwing hacks into catalyst to work around
> limitations in the package manager.
>
> Thanks,
> Zero
> >

If someone wants to work on fixing it.  The solution will require
extracting the NEEDED.ELF.2 info from the binpkg and confirming that the
links exist.  If any of them don't, then trigger the build from source.
Rejecting the existing binpkg.

You may also want to talk to blueness, he created a utility for looking
for broken elf links.