1 |
Hello, |
2 |
|
3 |
I'd like to bring a quick topic, preferably answered yes/no, preferably |
4 |
after reading the remaining part ;). |
5 |
|
6 |
Considering that python-r1 patches so far are clean, should I: |
7 |
|
8 |
a) integrate python-distutils-ng with python-r1 and change its API |
9 |
as listed below (the API changes don't collide with any used |
10 |
functionality), |
11 |
|
12 |
b) leave python-distutils-ng in place and work on distutils-r1 with |
13 |
a clean start. |
14 |
|
15 |
|
16 |
And now what changes in API will be necessary to make p-d-ng play nice |
17 |
with python-r1. I've assumed that functions prefixed with an underscore |
18 |
are private and didn't care about them. |
19 |
|
20 |
None of the listed features are used by any ebuild in the tree, unless |
21 |
I have missed something ;). |
22 |
|
23 |
1. Remove PYTHON_OPTIONAL -- I really dislike the way it is done |
24 |
(it's practically a switch to hardwire 'python?' in a few places, |
25 |
without any flexibility); |
26 |
|
27 |
2. Convert PYTHON_COMPAT to an array -- this will usually mean that |
28 |
ebuilds can't look up ${PYTHON_COMPAT} safely (the change is done |
29 |
for practical reasons); |
30 |
|
31 |
3. Stop passing Python ABI and executable as parameters to phase |
32 |
functions -- these are not really useful (since they are available |
33 |
as ${EPYTHON} and ${PYTHON} anyway. Removing them will allow me to |
34 |
implement a 'foreach' function being able to pass arbitrary |
35 |
parameters to invoked commands. |
36 |
|
37 |
What do you think? Should I change p-d-ng ABI like that (errr, how I |
38 |
hate that name) or just introduce a new eclass? |
39 |
|
40 |
-- |
41 |
Best regards, |
42 |
Michał Górny |