Carsten Lohrke <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sun, 14 Sep 2008 16:21:03 +0200:
> What I do strongly oppose is changing the meaning of the '!' symbol, as > blockers, which should remain real blockers will not be adjusted by us, > when changing an ebuild to EAPI 2++ in every case, since we're humans > after all. So, if you implement this, keep '!' as is and find another > symbol for these "soft" blockers. I had wondered about that, but since no devs were bringing it up, I thought it must not be as big a deal as I had thought. Now one has. >> ~ * A new src_prepare phase function is called after src_unpack. >> >> ~ * The old src_compile phase function is split into separate ~ >> src_configure and src_compile fuctions. > > All I do see is more complexity, but no real benefit. This is from a user's perspective, but there's a significant benefit to people with poor hardware. I began my Gentoo journey with memory that only marginally supported the bandwidth it was rated for and had to live with the related crashes, reboots, and restart-the-emerges. As such, I quickly learned the benefits of ccache and ebuid's step-by-step process. I sure could have used a separate configure step at that point! With configure separate, it wouldn't have had to be redone each time I crashed and had to restart. I could and often did re-issue the half completed make commands by hand, letting the package's own build system pick up where it left off, but that didn't fill in the blanks in portage's package data, and I had to reissue the ebuild compile command to do so. Only compile meant reconfigure too, which of course touched the various makefiles, forcing a recompile of the whole thing again -- and another chance at a crash while doing so. If configure had been a separate stage, all those makefiles wouldn't have been touched and the package's build system would have seen that everything was built already, which would have saved me an AWFUL lot of trouble. The unpack/prepare split wouldn't have been quite as useful as that was generally fast and crash resistant enough I didn't have problems with it, but it won't hurt, and would make user modification of existing ebuilds slightly easier. As for the dev perspective, based on my ebuild hacking to date, I can see a significant benefit for the two spits there as well. That the new phases match natural steps in most upstream package build processes where Gentoo formerly merged steps makes it that much simpler to trace down bugs when something goes wrong. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
