* Re: [gentoo-portage-dev] [PATCHES] setup.py install for Portage
@ 2014-08-22 22:32 99% ` Brian Dolbec
0 siblings, 0 replies; 1+ results
From: Brian Dolbec @ 2014-08-22 22:32 UTC (permalink / raw
To: gentoo-portage-dev
On Thu, 21 Aug 2014 22:19:38 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> Hello, everyone.
>
> Here is a rebase of my recent work on bringing setup.py install for
> Portage.
>
>
> About the patches:
>
> (1) teaches the self-update function to deal with PORTAGE_PYM_PATH
> that contains more packages than Portage itself. In particular, it
> makes it copy packages of Portage only rather than everything found
> in 'pym' :).
>
> (2) makes PORTAGE_PYM_PATH contain wherever Portage is loaded from
> rather than 'pym' subdirectory of PORTAGE_BASE_PATH. This makes the
> code work well when 'pym' directory is removed.
>
> (3) makes sure that all important test files are suffixed with .py so
> that they are installed by setup.py without extra hackery.
>
> (4) fixes all the remaining issues with tests, allowing them to be run
> on the installed copy of Portage.
>
> (5) replaces the Makefiles with setup.py. It's distutils with a few
> extensions -- mostly making it possible to install scripts to multiple
> locations, install data files recursively and override all the paths.
>
> (6) updates .travis.yml to run tests using setup.py, and also try
> installing and re-running tests after install.
>
> I will follow this thread with updated ebuild.
>
>
> About the new install layout:
>
> 1. /usr/lib/portage/pym no longer exists. Python files are installed
> directly to site-packages for each implementation (by default).
>
> 2. /usr/lib/portage/bin no longer contains copies of the scripts that
> are installed to /usr/bin and /usr/sbin.
>
> 3. All Python scripts have proper shebangs set by distutils. To fit
> this with how distutils usually works and how the eclass expects it
> to be done, my ebuild had done a few more changes:
>
> 3a. all programs from /usr/sbin are moved to /usr/bin, and all
> programs in /usr/bin are wrapped.
>
> 3b. The Portage internal tools are moved from /usr/lib/portage/bin
> to /usr/lib/portage/${EPYTHON} so that no Python mismatch is possible.
>
> 3c. /usr/lib/portage/bin became a symlink for external tool
> compatibility. It uses the 'last' Python implementation as chosen
> by distutils-r1.
>
>
> I have tested these changes for a while and I think Portage itself can
> handle them well. However, some of the external tools overrelying on
> Portage itself can be broken, eix in particular.
>
> In particular, tools that want to play with Portage internals need to
> export proper PORTAGE_BIN_PATH and PORTAGE_PYM_PATH before spawning
> them. The correct values can be obtained using portageq:
>
> $ portageq envvar PORTAGE_BIN_PATH
> /usr/lib/portage/python3.4
> $ portageq envvar PORTAGE_PYM_PATH
> /usr/lib64/python3.4/site-packages
>
>
> Please look through the patches and test at will :). Thanks.
>
> --
> Michał Górny
>
>
I have not tested these yet, but they mostly look good aside for the
couple questions I had (see individual replies).
I will begin some testing.
--
Brian Dolbec <dolsen>
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2014-08-21 20:19 [gentoo-portage-dev] [PATCHES] setup.py install for Portage Michał Górny
2014-08-22 22:32 99% ` Brian Dolbec
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox