Gilles Dartiguelongue schrieb: > Le lundi 21 janvier 2013 à 00:01 +0100, Thomas Sachau a écrit : >> Michał Górny schrieb: >>> Hello, >>> >>> There is a fair interest in multilib and while still early, it would be >>> a good moment to decide on how USE flags to use for it. >>> >>> The current attempts are mostly using USE=multilib which is not really >>> expressive and poor. What I would go for is a clear variable specifying >>> which targets package is built for. >>> >>> >>> This raises the following questions: >>> >>> 1) do we want the default ABI to be switchable? >>> >>> 2) do we want irrelevant ABIs to be visible to emerge users? >>> >>> By 2) I mean: do we want the users to see stuff like: >>> >>> MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1) >>> (-ppc64_abi2) (-ppc64_abi3) ..." >>> >>> or just the relevant part. >>> >>> To be honest, I don't know if there's other way to hide USE flags than >>> using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split >>> the flags per-arch, i.e. have: >>> >>> MULTILIB_AMD64="abi1 abi2 abi3" >>> MULTILIB_PPC64="abi1 abi2 abi3" >>> >>> with appropriate USE_EXPAND_HIDDEN set by profiles. >>> >>> >>> What are your thoughts? Which arches would like to use multilib? What >>> names for ABIs do you suggest? >>> >> >> So you want to re-implement multilib-portage in an eclass without the >> additional benefits a package-manager level implementation has? > > Well that's the point of the eclass that was proposed a few days ago > allow building multiple ABIs. Having clear USE-dep like python-r1.eclass > is imho the way to go. > > As said in another reply of this thread, USE=multilib really is a > solution that has its problems (no fine PM control for ABIs, slow > updates of emul-pkgs) to the current problem and portage-multilib, well > it's a subject that pops up from time to time I have no idea how and > will it will come nor do I have time to help on that front.
multilib-portage exists and works for years, the problem usually is, that posts about it are ignored until i write something about "planned to ask council", which results in new requests to be fulfilled (for the inclusion of this feature in the next EAPI). This could also get us rid of USE=multilib and the emul packages. ;-) > However this eclass would enable quick and easy per-ebuild support for > multiple ABIs just like python-r1 and friends, and this is a good thing > for every maintainer that wants to provide this kind of support. I know > I would, at least to get rid of the always lagging emul packages. As already written in another thread not long ago, the USE flag part (shown USE flags per arch and USE flag dependencies) will be pretty hard to implement at eclass level. So i will wait and see, if someone can surprise me with a solution, that works as good as multilib-portage without bad side effects or additional work for all sides. -- Thomas Sachau Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
