Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: Gentoo Developer Mailing List <gentoo-dev@l.g.o>
Subject: [gentoo-dev] [RFC] Multiple ABI support through package appending/partial removal
Date: Sun, 23 Sep 2012 22:10:50
Message-Id: 20120924000949.505e3439@pomiocik.lan
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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies