1 |
On Thu, 21 Aug 2014 22:19:38 +0200 |
2 |
Michał Górny <mgorny@g.o> wrote: |
3 |
|
4 |
> Hello, everyone. |
5 |
> |
6 |
> Here is a rebase of my recent work on bringing setup.py install for |
7 |
> Portage. |
8 |
> |
9 |
> |
10 |
> About the patches: |
11 |
> |
12 |
> (1) teaches the self-update function to deal with PORTAGE_PYM_PATH |
13 |
> that contains more packages than Portage itself. In particular, it |
14 |
> makes it copy packages of Portage only rather than everything found |
15 |
> in 'pym' :). |
16 |
> |
17 |
> (2) makes PORTAGE_PYM_PATH contain wherever Portage is loaded from |
18 |
> rather than 'pym' subdirectory of PORTAGE_BASE_PATH. This makes the |
19 |
> code work well when 'pym' directory is removed. |
20 |
> |
21 |
> (3) makes sure that all important test files are suffixed with .py so |
22 |
> that they are installed by setup.py without extra hackery. |
23 |
> |
24 |
> (4) fixes all the remaining issues with tests, allowing them to be run |
25 |
> on the installed copy of Portage. |
26 |
> |
27 |
> (5) replaces the Makefiles with setup.py. It's distutils with a few |
28 |
> extensions -- mostly making it possible to install scripts to multiple |
29 |
> locations, install data files recursively and override all the paths. |
30 |
> |
31 |
> (6) updates .travis.yml to run tests using setup.py, and also try |
32 |
> installing and re-running tests after install. |
33 |
> |
34 |
> I will follow this thread with updated ebuild. |
35 |
> |
36 |
> |
37 |
> About the new install layout: |
38 |
> |
39 |
> 1. /usr/lib/portage/pym no longer exists. Python files are installed |
40 |
> directly to site-packages for each implementation (by default). |
41 |
> |
42 |
> 2. /usr/lib/portage/bin no longer contains copies of the scripts that |
43 |
> are installed to /usr/bin and /usr/sbin. |
44 |
> |
45 |
> 3. All Python scripts have proper shebangs set by distutils. To fit |
46 |
> this with how distutils usually works and how the eclass expects it |
47 |
> to be done, my ebuild had done a few more changes: |
48 |
> |
49 |
> 3a. all programs from /usr/sbin are moved to /usr/bin, and all |
50 |
> programs in /usr/bin are wrapped. |
51 |
> |
52 |
> 3b. The Portage internal tools are moved from /usr/lib/portage/bin |
53 |
> to /usr/lib/portage/${EPYTHON} so that no Python mismatch is possible. |
54 |
> |
55 |
> 3c. /usr/lib/portage/bin became a symlink for external tool |
56 |
> compatibility. It uses the 'last' Python implementation as chosen |
57 |
> by distutils-r1. |
58 |
> |
59 |
> |
60 |
> I have tested these changes for a while and I think Portage itself can |
61 |
> handle them well. However, some of the external tools overrelying on |
62 |
> Portage itself can be broken, eix in particular. |
63 |
> |
64 |
> In particular, tools that want to play with Portage internals need to |
65 |
> export proper PORTAGE_BIN_PATH and PORTAGE_PYM_PATH before spawning |
66 |
> them. The correct values can be obtained using portageq: |
67 |
> |
68 |
> $ portageq envvar PORTAGE_BIN_PATH |
69 |
> /usr/lib/portage/python3.4 |
70 |
> $ portageq envvar PORTAGE_PYM_PATH |
71 |
> /usr/lib64/python3.4/site-packages |
72 |
> |
73 |
> |
74 |
> Please look through the patches and test at will :). Thanks. |
75 |
> |
76 |
> -- |
77 |
> Michał Górny |
78 |
> |
79 |
> |
80 |
|
81 |
I have not tested these yet, but they mostly look good aside for the |
82 |
couple questions I had (see individual replies). |
83 |
|
84 |
I will begin some testing. |
85 |
|
86 |
-- |
87 |
Brian Dolbec <dolsen> |