Re: [gentoo-dev] latest boost vs. eselected boost

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 19/01/12 03:27 AM, "Paweł Hajdan, Jr." wrote:
> On 1/19/12 9:05 AM, Johannes Huber wrote:
>> Summary of the comments: 1) Ebuilds should always pick the latest
>> boost version. 2) Boost should be compared to gcc, python, ruby
>> etc
>>
>> [1] https://bugs.gentoo.org/show_bug.cgi?id=335108
>
> Right, Tiziano Müller's (dev-zero) comments are pretty clear that
> ebuilds should use latest boost.
>
> I'm fine with last-riting eselect-boost, and I'm also fine with
> eselect-boost applying to ebuilds too, like eselect-python.
>
> What I mostly care about is consistency and principle of least
> surprise.
>

I thought there was a push to eventually de-slot boost?  (in which
case this issue just disappears)

Anyways, if we ARE going to keep boost slotted, we should probably
have a mechanism within ebuilds to select the boost version that will
be used -- simiar to/same as python and ruby (or perhaps closer to
autotools?  unsure which paradigm best fits).  Yes, I know how much of
a potential mess this could be and how much of a PITA it's going to be
to do.*  I'm not sure if using eselect-boost for this would be a good
idea, though; isn't eselect mainly just for the system?  IE, when a
user is using boost for their own stuffs?


* Given that python and ruby already need to do this, maybe it would
be a good idea to make an eclass and set of functions that generalize
this capability, and then convert the python and ruby eclasses and
ebuild to use (or at least inherit) the generalized eclass?  Seems
better than reinventing the wheel for every slotted build platform..

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk8YSecACgkQAJxUfCtlWe0mpwD/TClHGn/93VFTiuP7S7ZUnF5k
yDbm8jRbG2fL0vwiemgBAJ4uYSpFVuzAJgR/ZoDou94umBLarPdc2OxInnH/1QyY
=pzBv
-----END PGP SIGNATURE-----