Tiziano Müller schrieb: > 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. >
Can you also explain your statement? -- Thomas Sachau Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
