1 |
Hello, |
2 |
|
3 |
Since my previous idea of DYNAMIC_SLOTS proved too complex to design |
4 |
and implement, I would like to offer an another idea, based partially |
5 |
on what Ciaran mentioned. Before I start getting into details, I'd like |
6 |
to know your opinions, and what possible problems am I missing. To keep |
7 |
it clean, I will focus on Python ABIs but other languages and multilib |
8 |
could be handled in a similar manner. |
9 |
|
10 |
|
11 |
The problem |
12 |
=========== |
13 |
|
14 |
Right now, building packages for multiple Python ABIs is done using |
15 |
USE_EXPAND-based useflags. This is a working solution but it requires |
16 |
rebuilding the package for all ABIs whenever the chosen ABI list |
17 |
changes. |
18 |
|
19 |
While it may be not that important for most of the Python packages, it |
20 |
becomes such when it comes to things like boost or -- if we'd extend |
21 |
that to multilib -- say, llvm. In that case, whenever a newly-installed |
22 |
package requests a specific ABI, user has to spend twice as much time |
23 |
to rebuild the same version. |
24 |
|
25 |
|
26 |
The general idea |
27 |
================ |
28 |
|
29 |
While not getting too deep into ebuild syntax, the core part |
30 |
of the idea is to mark some of the USE_EXPAND variables 'special'. |
31 |
In this particular example, such a special flag group would be |
32 |
'PYTHON_TARGETS'. |
33 |
|
34 |
Now, let's consider user installs a new package with one |
35 |
python_targets_python2_7 enabled. The package is built and installed |
36 |
like usual but aside to regular vdb files an additional file |
37 |
is introduced, listing all the installed files as 'belonging' |
38 |
to python_targets_python2_7. |
39 |
|
40 |
If user enables python_targets_python3_2 on the same package, the PM |
41 |
doesn't trigger a full rebuild. Instead, it builds the package with |
42 |
the new flag being the only flag in PYTHON_TARGETS. The new files are |
43 |
installed over the installed package (and added to CONTENTS in vdb), |
44 |
and the files in install image are listed in vdb as 'belonging' |
45 |
to python_targets_python3_2. |
46 |
|
47 |
Whenever files from two ABIs collide, package manager either replaces |
48 |
the installed files if the 'new' ABI is considered 'better' than |
49 |
the old one or preserves it. This follows the current behavior when |
50 |
multiple ABIs are built, and later builds overwrite files from earlier |
51 |
ones. |
52 |
|
53 |
At the point, the additional file contains something like |
54 |
(ugly pseudo-syntax): |
55 |
|
56 |
/usr/lib64/python2.7/foo.py python_targets_python2_7 |
57 |
/usr/lib64/python3.2/foo.py python_targets_python3_2 |
58 |
/usr/share/doc/foo-1.2.3/README.bz2 python_targets_python2_7 \ |
59 |
python_targets_python3_2 |
60 |
|
61 |
Now, if user requests disabling python_targets_python2_7 |
62 |
on the package, the package manager may not rebuild it as well. |
63 |
Instead, it removes python_targets_python2_7 from the above list, |
64 |
and unmerges the files which don't belong into any other ABI. |
65 |
|
66 |
Sadly, this will not 'downgrade' common files to another ABI |
67 |
but I believe that it is not really a killer-feature. |
68 |
|
69 |
|
70 |
Installing new packages and upgrading existing |
71 |
============================================== |
72 |
|
73 |
Whenever a new package is to be built and multiple ABIs are requested, |
74 |
the package manager should split the build process between particular |
75 |
ABIs. Preferably, it should build all of them one-by-one, recording |
76 |
the 'belongs' entries from the image and then install them as a single |
77 |
package. |
78 |
|
79 |
Whenever a package is to be upgraded, all ABIs have to rebuilt. |
80 |
The package manager can handle it as a regular package upgrade, not |
81 |
considering 'belongs' entries more than in a fresh package install. |
82 |
|
83 |
Whenever a package is removed completely, the 'belongs' entries need |
84 |
not to be considered at all. |
85 |
|
86 |
|
87 |
Backwards compatibility |
88 |
======================= |
89 |
|
90 |
The solution aims to be fully compatible with package managers |
91 |
not supporting it. They should see it as a regular package with |
92 |
selected useflags, and an additional opaque vdb file. |
93 |
|
94 |
When such a package manager attempts to rebuild or upgrade such |
95 |
package, the vdb file should be removed, thus not introducing any |
96 |
ambiguity for PMs supporting it. The package removal is unaffected |
97 |
at all. |
98 |
|
99 |
-- |
100 |
Best regards, |
101 |
Michał Górny |