Gentoo Archives: gentoo-dev

From: Mike Frysinger <vapier@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] My wishlist for EAPI 5
Date: Fri, 29 Jun 2012 05:26:13
In Reply to: [gentoo-dev] My wishlist for EAPI 5 by Richard Yao
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
> 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


File name MIME type
signature.asc application/pgp-signature