-----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-----
