On Wednesday 20 June 2012 16:25:30 Richard Yao wrote: > Multilib (and/or multiarch) support
Thomas already has multilib documents put together for review. multiarch doesn't make sense for us, and even if it did, there's no way it'd be spec-ed out in a reasonable time frame for EAPI=5 (or even 6 or 7 or ...). > The current binaries cause a great deal of pain, particularly when a > user does not want to upgrade something. I had this problem with WINE > and glibc because I wanted to avoid the reverse memcpy() fiasco on my > systems. This situation would have been avoided entirely if the package > manager supported multilib. i don't buy this argument and makes me think when you say "multilib", you don't actually mean "multilib". > Automated epatch_user support > Users should be able to test patches without modifying their ebuilds. > This also saves developer time because we don't need to navigate the > portage tree (or an overlay), make a change and test it. We could just > dump the patch in the appropriate directory and build. putting forth an idea is one thing. working out the technical aspects is different. this sounds like something destined for EAPI=6: currently, epatch_user uses epatch, and that provides a lot of dynamic patch support that doesn't fit well with being spec-ed out / encoded in PMS. > Parallel make checks SGTM > POSIX Shell compliance > There has been a great deal of work done to give the user full control > of what is on his system and there is more that we can do there. In > particular, I think a lean Gentoo Linux system should be able to use > busybox sh and nothing else. That requires POSIX shell compliance. > OpenRC init scripts support this and the configure scripts support this. > The few exceptions are bugs that are addressed by the Gentoo BSD > developers. As such, I think we should make EAPI=5 use POSIX shell by > default. If an ebuild requires bash, we can allow the ebuild to declare > that (e.g. WANT_SH=bash), but that should be the exception and not the > rule. not a chance, and your logic about "choice" really makes no sense in the ebuild context. read the archives wrt Roy Maples (sadly) burning out for in- depth details as to why this is a no-go. -mike
signature.asc
Description: This is a digitally signed message part.