Gentoo Archives: gentoo-portage-dev

From: Brian Dolbec <dolsen@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] [PATCHES] setup.py install for Portage
Date: Fri, 22 Aug 2014 22:33:47
Message-Id: 20140822153229.7230b419.dolsen@gentoo.org
In Reply to: [gentoo-portage-dev] [PATCHES] setup.py install for Portage by "Michał Górny"
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>