Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Alec Warner <antarus@g.o>
Subject: Re: new `usex` helper
Date: Wed, 21 Sep 2011 09:37:15 -0700
On Wed, Sep 21, 2011 at 6:11 AM, Donnie Berkholz <dberkholz@g.o> 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
>


Replies:
Re: new `usex` helper
-- Donnie Berkholz
References:
Re: new `usex` helper
-- Donnie Berkholz
Re: new `usex` helper
-- Brian Harring
Re: new `usex` helper
-- Donnie Berkholz
Re: new `usex` helper
-- Brian Harring
Re: new `usex` helper
-- Donnie Berkholz
Re: new `usex` helper
-- Brian Harring
Re: new `usex` helper
-- Donnie Berkholz
Re: new `usex` helper
-- Brian Harring
Re: new `usex` helper
-- Donnie Berkholz
Re: new `usex` helper
-- Brian Harring
Re: new `usex` helper
-- Donnie Berkholz
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: new `usex` helper
Next by thread:
Re: new `usex` helper
Previous by date:
Re: finding reverse dependencies for arch testing (and other purposes)
Next by date:
Re: Please don't use IUSE=static-libs unless really necessary


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.