From: "W. Trevor King" <[email protected]>

The current approach to avoiding problems due to stale binary packages
with untracked ABI dependencies is to disable binpkg use during
troublesome sections of the build (e.g. seed updates).  I think that a
cleaner solution would be to use a configurable spec option
blacklisting binpkgs for troublesome packages.  For example, in a
stage1 with update_seed enabled, the Portage emerge (before the seed
update) has:

  …
  removed '/usr/portage/packages/sys-devel/gcc-4.6.3.tbz2'
  removed '/usr/portage/packages/sys-devel/gcc-config-1.7.3.tbz2'
  emerge --quiet --usepkg --buildpkg --newuse --oneshot --nodeps --update 
sys-apps/portage
  …

During the seed update, the rest of the packages can use preexisting
binpkgs from earlier builds:

  …
  >>> Emerging binary (1 of 17) sys-devel/gnuconfig-20121010
  >>> Installing (1 of 17) sys-devel/gnuconfig-20121010
  >>> Emerging binary (2 of 17) app-misc/mime-types-9
  >>> Installing (2 of 17) app-misc/mime-types-9
  >>> Emerging (3 of 17) sys-libs/timezone-data-2013a
  >>> Installing (3 of 17) sys-libs/timezone-data-2013a
  …

I'm not sure yet why some packages (e.g. timezone-data) don't use the
prexisting binpkgs, even though they do exist:

  # ls packages/default/stage1-i686-2013.1/sys-libs/timezone-data-201*
  packages/default/stage1-i686-2013.1/sys-libs/timezone-data-2012j.tbz2
  packages/default/stage1-i686-2013.1/sys-libs/timezone-data-2013a.tbz2

Later in the stage1 build, GCC is not installed from a binary package
(because this package was removed earlier):

  …
  >>> Emerging binary (59 of 75) virtual/libc-0 for /tmp/stage1root/
  >>> Installing (59 of 75) virtual/libc-0 to /tmp/stage1root/
  >>> Emerging (60 of 75) sys-devel/gcc-4.6.3 for /tmp/stage1root/
  >>> Installing (60 of 75) sys-devel/gcc-4.6.3 to /tmp/stage1root/
  …

I think this approach is cleaner because it:

* Avoids problems we've already seen by blacklisting troublesome
  packages.
* Allows you to reuse binary packages in the seed update stage, at the
  cost of rebuilding gcc for your stage1root.
* Can be applied to any stage, so you don't get bitten by stale
  binpkgs in stage2, etc. due to a snapshot update.
* Can be overridden by folks who know some blacklisted package will be
  fine for their combination of seed, snapshot, and pkgcache.

W. Trevor King (2):
  spec: Add binpkg_blacklist option for troublesome packages
  Revert "don't build packages during update_seed"

 modules/generic_stage_target.py     | 4 +++-
 targets/stage1/stage1-chroot.sh     | 4 ++--
 targets/support/chroot-functions.sh | 5 +++++
 3 files changed, 10 insertions(+), 3 deletions(-)

-- 
1.8.2


Reply via email to