Optimize root fs build

[edannenberg]

Full context: #99

@berney said:
I think my algorithm I stated above should work for emerging correct packages with working soname dependencies whislt trying to minimal wasted time rebuilding packages that have already been built..To reiterate more clearly it would be: -

1. Try emerging binary packages only with soname dependency checking: emerge --usepkgonly --ignore-soname-deps=n ....
2. If above worked to goto end else goto 3
3. emerge packages from binaries and source: emerge --usepkg ....
   • This will generate soname metadata
4. Try emerging binary packages only with soname dependency checking: emerge --usepkgonly --ignore-soname-deps=n ....
5. If above worked goto end else goto 6
6. try emerging packages with binary package ignored: emerge --usepkg --usepkg-exclude $atom ..., where $atom is the main package like memcached.
   • This should build main package from source, and dependencies from binaries if they exist and/or source if not
7. Try emerging binary packages only with soname dependency checking: emerge --usepkgonly --ignore-soname-deps=n ....
8. If this works goto end else...
9. ...
   10. Try emergy from source only: emerge ... (no --usepkg)
   11. Try emerging binary packages only with soname dependency checking: emerge --usepkgonly --ignore-soname-deps=n ....
   • This should work otherwise portage/ebuilds/packages or gentoo/system are broken.

@berney said: The above is a bit recursive, at some point it's probably best to switch to rebuilding it all from source and not using any binary packages, producing new binaries packages.

Alternatively a revdep-rebuild-like tool that works on specified roots. I think this should be done for QA purposes anyway. When it detects breakages, something like the algorithm above could be used to automatically find a solution as long as the portage, the ebuilds, and the packages themselves are not broken.

Essentially all binary packages would be created by installing at the build container root first, before using the created binary packages to populate the custom root. The tricky part is to only run the first install phase if a binary package does not exist yet.

I'll probably shoot for something simple first, i.e. just check if --usepkgonly throws an error and use that to decide if to run the first phase or not. Ideally this would be more fine grained as outlined by @berney, though that might be a bit much. While it would detect issues like with that memcached version, it's probably rarely needed in practice, this was a bug in the memcached ebuild after all. So I'm not sure it is worth the increased complexity. We'll see.

[azimut]

I wonder if this will cover installation and reinstallation of -9999 ebuilds. If not, might be we can add support for them. Not sure how though. Right now I am ok with just rm the binary precompiled package. One day hopefully hooked into the commit history on jenkins.

This project might be can have a hook to delete the 9999 package when a flag is set. Dunno for now.

[azimut]

As a note. I have been trying --usepkgonly but seems to always want to emerge old packages if available. I tried with --rebuild-if-new-rev but same result.

[berney]

As a note. I have been trying --usepkgonly but seems to always want to emerge old packages if available. I tried with --rebuild-if-new-rev but same result.

With --usepkgonly it will use the latest binary available. It won't use newer versions if they don't have binary packages available. E.g. some/atom-1.0.0 (binary), some/atom-1.0.1 (no binary), it will use 1.0.0, whereas if you did a standard emerge it would use 1.0.1 (assuming it's not masked).

I typically have --usepkg and --buildpkg enabled, so that it will use binaries if available and produce binaries. This ensures I get the latest builds and that subsequent emerges are faster.

[berney]

I hit the soname dep issue in builder/bob-musl with its build.sh calling configure_eix, which in bob-core/build-root.sh calls eix-update (which is a symlink to eix). eix was installed, but the problem was it was installed from a binary package, and was linked to libc.so.6, which didn't exist. There was only a libc.so, in /usr/lib/.

I removed the packages cache and then on building bob-musl it emerged from source, and this time was linked to libc.so.

From what I can tell revdep-rebuild (from gentoolkit) doesn't properly support scanning an alternative root. But maybe I just don't know the right way to invoke it. If I try ROOT=/emerge-root revdep-rebuild it complains about trying to load /emerge-root/etc/revdep-rebuild/... config. You can specify scan directories, but I think it find libraries in the real-root rather than anchored to the /emerge-root...