Gentoo Archives: gentoo-catalyst

From: "W. Trevor King" <wking@×××××××.us>
To: Catalyst <gentoo-catalyst@l.g.o>
Cc: "W. Trevor King" <wking@×××××××.us>
Subject: [gentoo-catalyst] [PATCH 0/2] Blacklisting binary packages
Date: Tue, 16 Apr 2013 19:42:43
Message-Id: cover.1366137972.git.wking@tremily.us
In Reply to: [gentoo-catalyst] Re: [PATCH v3] Strengthen update_seed to update @system and @world with dependencies by "W. Trevor King"
1 From: "W. Trevor King" <wking@×××××××.us>
2
3 The current approach to avoiding problems due to stale binary packages
4 with untracked ABI dependencies is to disable binpkg use during
5 troublesome sections of the build (e.g. seed updates). I think that a
6 cleaner solution would be to use a configurable spec option
7 blacklisting binpkgs for troublesome packages. For example, in a
8 stage1 with update_seed enabled, the Portage emerge (before the seed
9 update) has:
10
11
12 removed '/usr/portage/packages/sys-devel/gcc-4.6.3.tbz2'
13 removed '/usr/portage/packages/sys-devel/gcc-config-1.7.3.tbz2'
14 emerge --quiet --usepkg --buildpkg --newuse --oneshot --nodeps --update sys-apps/portage
15
16
17 During the seed update, the rest of the packages can use preexisting
18 binpkgs from earlier builds:
19
20
21 >>> Emerging binary (1 of 17) sys-devel/gnuconfig-20121010
22 >>> Installing (1 of 17) sys-devel/gnuconfig-20121010
23 >>> Emerging binary (2 of 17) app-misc/mime-types-9
24 >>> Installing (2 of 17) app-misc/mime-types-9
25 >>> Emerging (3 of 17) sys-libs/timezone-data-2013a
26 >>> Installing (3 of 17) sys-libs/timezone-data-2013a
27
28
29 I'm not sure yet why some packages (e.g. timezone-data) don't use the
30 prexisting binpkgs, even though they do exist:
31
32 # ls packages/default/stage1-i686-2013.1/sys-libs/timezone-data-201*
33 packages/default/stage1-i686-2013.1/sys-libs/timezone-data-2012j.tbz2
34 packages/default/stage1-i686-2013.1/sys-libs/timezone-data-2013a.tbz2
35
36 Later in the stage1 build, GCC is not installed from a binary package
37 (because this package was removed earlier):
38
39
40 >>> Emerging binary (59 of 75) virtual/libc-0 for /tmp/stage1root/
41 >>> Installing (59 of 75) virtual/libc-0 to /tmp/stage1root/
42 >>> Emerging (60 of 75) sys-devel/gcc-4.6.3 for /tmp/stage1root/
43 >>> Installing (60 of 75) sys-devel/gcc-4.6.3 to /tmp/stage1root/
44
45
46 I think this approach is cleaner because it:
47
48 * Avoids problems we've already seen by blacklisting troublesome
49 packages.
50 * Allows you to reuse binary packages in the seed update stage, at the
51 cost of rebuilding gcc for your stage1root.
52 * Can be applied to any stage, so you don't get bitten by stale
53 binpkgs in stage2, etc. due to a snapshot update.
54 * Can be overridden by folks who know some blacklisted package will be
55 fine for their combination of seed, snapshot, and pkgcache.
56
57 W. Trevor King (2):
58 spec: Add binpkg_blacklist option for troublesome packages
59 Revert "don't build packages during update_seed"
60
61 modules/generic_stage_target.py | 4 +++-
62 targets/stage1/stage1-chroot.sh | 4 ++--
63 targets/support/chroot-functions.sh | 5 +++++
64 3 files changed, 10 insertions(+), 3 deletions(-)
65
66 --
67 1.8.2

Replies