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----- |