On Wed, Sep 21, 2011 at 6:11 AM, Donnie Berkholz <dberkh...@gentoo.org> wrote:
> On 14:20 Tue 20 Sep , Brian Harring wrote:
>> On Sun, Sep 18, 2011 at 10:16:46PM -0500, Donnie Berkholz wrote:
>> > OK, so the implication of what you're saying is that everything in
>> > eutils.eclass, base.eclass, toolchain-funcs.eclass,
>> > flag-o-matic.eclass, versionator.eclass, multilib.eclass,
>> > prefix.eclass, savedconfig.eclass, and maybe even linux-info.eclass
>> > and autotools{,-utils}.eclass should go into EAPI. All that stuff is
>> > pretty generally useful features.
>>
>> Approximately... yes. Some of that (base.eclass for example) is EAPI
>> compatibility that can't be folded in (would require retroactively
>> addding to an EAPI), others aren't yet stabilized (true multilib for
>> example, seems to still be under discussion), etc.
>>
>> You get the jist.
>
> Yep, and I'm completely on the opposite end of the spectrum. =)
>
>> > > They should, but api compatibility of an eclass *can* be fluid- in
>> > > the past it was a locked API purely because of portage environment
>> > > saving issues. That's been resolved, there isn't any strict
>> > > requirement that the eclass maintain API compat now. You're
>> > > trying to rely on people doing best practices- for format building
>> > > blocks (use_with/usex/unpack/etc), that's not sane.
>> >
>> > Which still pisses me off. It's like a shared library changing its
>> > API without bumping SONAME.
>>
>> I think you're viewing this wrong; if we're talking about openssl
>> breaking API/ABI w/out bumping soname, sure. It's one component that
>> is distributed alone, but consumed by others. There is no way to
>> atomically deploy the new API at the same time as all of the consumers
>> being updated for it.
>>
>> That is /not/ the case of gentoo-x86; eclasses for us are equivalent
>> to bundled libs. Overlay stacking just makes it possible for a third
>> party component to reach in and use what is effectively an internal
>> lib.
>
> Not really, because when you update a bundled lib you actually make your
> whole app compile with it. People change the APIs of eclasses and then
> just let every internal consumer (ebuilds in gentoo-x86) break. Maybe if
> we put the burden on the one who changed the API, like the Linux kernel
> model, it would bother me less.
I think people do this for three reasons.
1) There are no refactoring tools that I know of for bash.
2) There exist some package maintainers that will yell at you if you
touch their packages for any reason.
3) Breaking things means they get fixed.
We have this notify -> deprecate -> break workflow; I actually don't
mind it (but only because I've seen it used elsewhere.)
-A
>
> --
> Thanks,
> Donnie
>
> Donnie Berkholz
> Council Member / Sr. Developer
> Gentoo Linux
> Blog: http://dberkholz.com
>
