Gentoo Archives: gentoo-dev

From: Ian Stakenvicius <axs@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [RFC] Multiple ABI support through package appending/partial removal
Date: Mon, 24 Sep 2012 14:10:34
Message-Id: 50606991.4060301@gentoo.org
In Reply to: [gentoo-dev] [RFC] Multiple ABI support through package appending/partial removal by "Michał Górny"
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA256
3
4 On 23/09/12 06:09 PM, Michał Górny wrote:
5 > Hello,
6 >
7 > Since my previous idea of DYNAMIC_SLOTS proved too complex to
8 > design and implement, I would like to offer an another idea, based
9 > partially on what Ciaran mentioned. Before I start getting into
10 > details, I'd like to know your opinions, and what possible problems
11 > am I missing. To keep it clean, I will focus on Python ABIs but
12 > other languages and multilib could be handled in a similar manner.
13 >
14 >
15 > The problem ===========
16 >
17 > Right now, building packages for multiple Python ABIs is done
18 > using USE_EXPAND-based useflags. This is a working solution but it
19 > requires rebuilding the package for all ABIs whenever the chosen
20 > ABI list changes.
21 >
22 > While it may be not that important for most of the Python packages,
23 > it becomes such when it comes to things like boost or -- if we'd
24 > extend that to multilib -- say, llvm. In that case, whenever a
25 > newly-installed package requests a specific ABI, user has to spend
26 > twice as much time to rebuild the same version.
27 >
28 >
29 > The general idea ================
30 >
31 > While not getting too deep into ebuild syntax, the core part of the
32 > idea is to mark some of the USE_EXPAND variables 'special'. In this
33 > particular example, such a special flag group would be
34 > 'PYTHON_TARGETS'.
35 >
36 > Now, let's consider user installs a new package with one
37 > python_targets_python2_7 enabled. The package is built and
38 > installed like usual but aside to regular vdb files an additional
39 > file is introduced, listing all the installed files as 'belonging'
40 > to python_targets_python2_7.
41 >
42 > If user enables python_targets_python3_2 on the same package, the
43 > PM doesn't trigger a full rebuild. Instead, it builds the package
44 > with the new flag being the only flag in PYTHON_TARGETS. The new
45 > files are installed over the installed package (and added to
46 > CONTENTS in vdb), and the files in install image are listed in vdb
47 > as 'belonging' to python_targets_python3_2.
48 >
49 > Whenever files from two ABIs collide, package manager either
50 > replaces the installed files if the 'new' ABI is considered
51 > 'better' than the old one or preserves it. This follows the current
52 > behavior when multiple ABIs are built, and later builds overwrite
53 > files from earlier ones.
54 >
55 > [ Snip! ]
56
57
58 This -could- be done, for testing purposes, entirely within an eclass,
59 if you'd like. Generate the file lists for each target during the
60 targets-specific src_install phase and install 'em to
61 /usr/share/${PN}-${PVR} , and then read 'em back at src_prepare if the
62 package has already been installed. Worth a shot to see if this is
63 really doable..
64
65 For testing purposes (or maybe as an overall solution) src_install
66 could copy back all the currently-installed files from ${EROOT} into
67 ${D} for the targets that are being kept.. (probably prior to the
68 'real' src_install functions so updated files overwrite the old ones)
69
70 -----BEGIN PGP SIGNATURE-----
71 Version: GnuPG v2.0.19 (GNU/Linux)
72
73 iF4EAREIAAYFAlBgaZEACgkQ2ugaI38ACPBi9gD/TjXQbsIFrtVpX/9wewNF2tnV
74 aITgy/JOR67EprpeMucBAKUzGtbDu/8fU4B8jXiy+4VODj6X1T/CqpK7EamzLaV3
75 =rOcp
76 -----END PGP SIGNATURE-----