-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 23/09/12 06:09 PM, Michał Górny wrote:
> Hello,
>
> Since my previous idea of DYNAMIC_SLOTS proved too complex to
> design and implement, I would like to offer an another idea, based
> partially on what Ciaran mentioned. Before I start getting into
> details, I'd like to know your opinions, and what possible problems
> am I missing. To keep it clean, I will focus on Python ABIs but
> other languages and multilib could be handled in a similar manner.
>
>
> The problem ===========
>
> Right now, building packages for multiple Python ABIs is done
> using USE_EXPAND-based useflags. This is a working solution but it
> requires rebuilding the package for all ABIs whenever the chosen
> ABI list changes.
>
> While it may be not that important for most of the Python packages,
> it becomes such when it comes to things like boost or -- if we'd
> extend that to multilib -- say, llvm. In that case, whenever a
> newly-installed package requests a specific ABI, user has to spend
> twice as much time to rebuild the same version.
>
>
> The general idea ================
>
> While not getting too deep into ebuild syntax, the core part of the
> idea is to mark some of the USE_EXPAND variables 'special'. In this
> particular example, such a special flag group would be
> 'PYTHON_TARGETS'.
>
> Now, let's consider user installs a new package with one
> python_targets_python2_7 enabled. The package is built and
> installed like usual but aside to regular vdb files an additional
> file is introduced, listing all the installed files as 'belonging'
> to python_targets_python2_7.
>
> If user enables python_targets_python3_2 on the same package, the
> PM doesn't trigger a full rebuild. Instead, it builds the package
> with the new flag being the only flag in PYTHON_TARGETS. The new
> files are installed over the installed package (and added to
> CONTENTS in vdb), and the files in install image are listed in vdb
> as 'belonging' to python_targets_python3_2.
>
> Whenever files from two ABIs collide, package manager either
> replaces the installed files if the 'new' ABI is considered
> 'better' than the old one or preserves it. This follows the current
> behavior when multiple ABIs are built, and later builds overwrite
> files from earlier ones.
>
> [ Snip! ]
This -could- be done, for testing purposes, entirely within an eclass,
if you'd like. Generate the file lists for each target during the
targets-specific src_install phase and install 'em to
/usr/share/${PN}-${PVR} , and then read 'em back at src_prepare if the
package has already been installed. Worth a shot to see if this is
really doable..
For testing purposes (or maybe as an overall solution) src_install
could copy back all the currently-installed files from ${EROOT} into
${D} for the targets that are being kept.. (probably prior to the
'real' src_install functions so updated files overwrite the old ones)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlBgaZEACgkQ2ugaI38ACPBi9gD/TjXQbsIFrtVpX/9wewNF2tnV
aITgy/JOR67EprpeMucBAKUzGtbDu/8fU4B8jXiy+4VODj6X1T/CqpK7EamzLaV3
=rOcp
-----END PGP SIGNATURE-----
