Re: [gentoo-catalyst] Binary package dependencies and update_seed

[Brian Dolbec]

On Thu, 2013-04-11 at 14:53 -0400, W. Trevor King wrote:
> On Thu, Apr 11, 2013 at 11:22:54AM -0700, Matt Turner wrote:
> > On Thu, Apr 11, 2013 at 10:09 AM, W. Trevor King <wking@×××××××.us> wrote:
> > > In order to avoid problems like this, it's probably a
> > > good idea to remove all the cached stuff with something like [1]:
> > >
> > >   $ rm -rf --one-file-system /var/tmp/catalyst/{kerncache,packages,tmp}
> > >
> > > before building your stage1.
> >
> > Not sure this is the way to go. I'll have to think through the
> > implications. Consider your stage1 build dies with some stupid tree
> > breakage that you can fix in your portage snapshot and restart the
> > stage build. This is going to cause your stage to rebuild everything.
>
> There shouldn't be a need to clear the caches unless you've changed
> the specs or sources.  Presumably you had to change something to fix
> whatever killed stage1.  If that was an ebuild problem, it's unlikely
> that your fix changed an ABI without also changing the package version
> and you should be ok keeping the old binary packages.
>
> > Wouldn't disabling the use of binary packages during the seed stage
> > update fix this?
>
> Disabling creation of binary packages during the seed stage update
> would help, and disabling the use of binary packages during the stage1
> build would help.  However, what if you have built a binary package
> for GCC and then you update your tree to something that builds
> libmpc.so.3.  In this case, you're in trouble if you use your old GCC
> binary packages anywhere based on the new tree.
>
> Cheers,
> Trevor
>

OK, When I first discovered the update_seed problem, I discovered
several (potential) bugs in the code that could cause failures.  My main
error was due to using binary pkgs which were built against libmpc.so.2.

I talked with Zac (and he agreed) portage _SHOULD_ be checking
NEEDED.ELF.2 which lists the actual libs it is linked to.  There is an
open bug for it in bugzie (sorry, I'm too tired to look for it).  If a
package manager supports installing binpkgs, then it should ensure it is
not installing a broken pkg due to mismatched lib links.

Everything else that is done in catalyst to avoid that is really just a
workaround until the package manager is fixed.

Blueness recently wrote a utility that scanned NEEDED.ELF.2 and looked
for broken/mismatched lib deps.  Perhaps he could help in getting
portage's binpkg handlers updated to check that the binpkg's lib deps
are met for it to qualify to be used.