[gentoo-dev] Re: EAPI-2

[Duncan]

Carsten Lohrke <carlo@g.o> posted
200809141621.11069.carlo@g.o, 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