Am Sonntag, den 05.04.2009, 10:18 +0200 schrieb Thomas Sachau: > Mike Frysinger schrieb: > > On Saturday 04 April 2009 08:59:22 Thomas Sachau wrote: > >> i would like to hear about other opinions about real multilib support > >> within our tree and package managers. From what i know, there are mainly 2 > >> different ideas: > >> > >> 1. Do the main stuff in the package manager (e.g. if the ARCH is amd64 and > >> the package has x86 keyword, the package manager adds a lib32 useflag, > >> which would additionally install the 32bit variant of that package together > >> with the normal 64bit install). > >> > >> pro: -much lesser work for package maintainers > >> > >> contra: -needs addition in PMS and support in the pms, which will need > >> some > >> work on their side > > > > get a *working* implementation first and *then* worry about specing it. > > once > > you have something running with portage, the spec should fall naturally > > out. > > previous multilib methods attempted to spec things out without any real > > code > > and they've all just died. > > > >> 2. Do the main stuff in the ebuilds themselves (e.g. an additional eclass > >> multilib-native.eclass, any ebuild with 32bit support would then need > >> adaption and of course inheriting that eclass) > > > > this is dead end and useless overhead, and i would reject it from any core > > package someone would try to merge. > > -mike > > > From what i got until now, it seems that all answers prefer this option, so i > would like to move > forward and create some aggreement on how this should look like or some > implementation that at least > the majority can accept. With this, i would also like to see any changes that > need an EAPI to get > into EAPI-3. No. Won't happen.
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
