On 05/23/2012 01:00 PM, Pacho Ramos wrote:
> El mié, 23-05-2012 a las 10:31 +0100, Markos Chandras escribió:
>> On Wed, May 23, 2012 at 9:04 AM, Pacho Ramos <pacho@gentoo.org> wrote:
>>> El mié, 23-05-2012 a las 06:39 +1000, Michael escribió:
>>>> On 2012-05-22 03:46, Alexandre Rostovtsev wrote:
>>>>> On May 20, autools.eclass was changed to no longer inherit eutils, see
>>>>> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?r1=1.133&r2=1.134
>>>>>
>>>>> Relying on autotools.eclass for your eutils needs was always a terrible
>>>>> idea, but a few ebuilds did it anyway. Those ebuilds are now *broken*
>>>>> since they can no longer use epatch. See bug #416847 for an example.
>>>>>
>>>>> Check your ebuilds to make sure you inherit eutils in anything that uses
>>>>> epatch!
>>>>>
>>>>> -Alexandre Rostovtsev.
>>>>>
>>>>>
>>>>>
>>>> Since eutils inherits multilib and user, the breakage extends beyond epatch.
>>>> For example, I just saw bug #417153, where a user reported failed calls
>>>> to enew{user,group}.
>>>>
>>>>
>>>>
>>>
>>> The autotools.eclass change should probably be reverted until things are
>>> properly checked I think (and I will do it tomorrow if nobody disagrees)
>>
>> It is far too late to do that. What is done is done. Let try and fix
>> what is still broken
>>
>> Regards,
>> Markos
>>
>>
>
> But we still have no idea what kind of commands provided by eutils and
> eclasses inheritted by it are now missing, epatch usage was fixes,
> enewgroup/user will probably be done but... other missing commands could
> still appear in the tree :|

I wrote a simple, stupid script just a moment ago. Please don't show it
to anybody who knows how to write in Python

It shows all missing inherits, not just the ones causing failures, but
it could prolly be adjusted to do that instead.

Cheers,
Kacper

On Wed, 23 May 2012 11:28:13 +0300
Petteri Räty <betelgeuse@gentoo.org> wrote:

> On 22.5.2012 8.53, Michał Górny wrote:
> >> Excuse me but the way this change was handled is a bit depressing.
> >> First, the ebuilds should have been fixed to inherit eutils and then
> >> remove eutils from autotools. Now, a bunch of ebuilds are broken out
> >> of nowhere. I don't believe this issue was that urgent in order to
> >> justify the significant breakage of portage tree.
> >
> > First of all, to quote devmanual:
> >
> > | Before updating eutils or a similar widely used eclass, it is best to
> > | email the gentoo-dev list. It may be that your proposed change is
> > | broken in a way you had not anticipated> [...]. If you don't email
> > | gentoo-dev first, and end up breaking something, expect to be in a
> > | lot of trouble.
> >
> > Not that this disrespect for this rule is something new...
> >
>
> Even more important is the next chapter:
>
> "When removing a function or changing the API of an eclass, make sure
> that it doesn't break any ebuilds in the tree, and post a notice to
> gentoo-dev at least 30 days in advance, preferably with a patch included."
>
> This qualifies as changing the API of an eclass. This chapter comes from
> a council decision:
>
> http://www.gentoo.org/proj/en/council/meeting-logs/20111108-summary.txt

I don't see how removing an inherit is breaking an eclass' API. The
functionality of the eclass itself does not change. Yes if you want to get
technical you previously had access to functions from other eclasses by
reaching through it, but that's a side effect that shouldn't be relied upon.
If we do, then making a change to an eclass not only requires an audit of all
the ebuilds using that eclass, but also any eclasses that inherit it and all
of their ebuilds and so on and so forth. Ebuilds should be inheriting what
they need, not relying on other eclasses to do it for them (the exception of
course is "meta" or "base" type eclasses like kde, gnome, or java (i think?)
that are designed to work this way). The breakage here is a perfect example
how a simple change can have consequences that even a senior developer can
overlook when this practice isn't followed.

That said, I do think adding the eutils inherit back until people can audit
their ebuilds seems like the sanest thing to do. Normally I'd say just fix
your ebuilds, but I hate it when stable breaks.


--
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org

On 05/23/2012 11:11 PM, Ryan Hill wrote:
> On Mon, 21 May 2012 21:04:44 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
>
>> Looks like ebuilds not inheriting eutils directly even using epatch are
>> a lot as I have seen running:
>> grep inherit $(grep -r epatch */*/*.ebuild| cut -d: -f1) | grep -v
>> eutils
>>
>> Maybe they should be checked and a repoman warning should be added when
>> an ebuild is using epatch without inheriting eutils directly, otherwise
>> this problem could reappear if some other eclass no longer inherit it in
>> the future :-/
>
> Maybe we should make eutils inheritance implicit so all ebuilds get epatch
> and friends automatically. Is there really that much overhead? Or am I
> missing something obvious?

Do you mean in EAPI 5? We're already planning to include epatch, as part
of the epatch_user thing.
--
Thanks,
Zac

On Mon, 21 May 2012 21:04:44 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> Looks like ebuilds not inheriting eutils directly even using epatch are
> a lot as I have seen running:
> grep inherit $(grep -r epatch */*/*.ebuild| cut -d: -f1) | grep -v
> eutils
>
> Maybe they should be checked and a repoman warning should be added when
> an ebuild is using epatch without inheriting eutils directly, otherwise
> this problem could reappear if some other eclass no longer inherit it in
> the future :-/

Maybe we should make eutils inheritance implicit so all ebuilds get epatch
and friends automatically. Is there really that much overhead? Or am I
missing something obvious?


--
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org

On Wed, 23 May 2012 23:09:14 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> On 05/23/2012 11:11 PM, Ryan Hill wrote:
> > On Mon, 21 May 2012 21:04:44 +0200
> > Pacho Ramos <pacho@gentoo.org> wrote:
> >
> >> Looks like ebuilds not inheriting eutils directly even using epatch are
> >> a lot as I have seen running:
> >> grep inherit $(grep -r epatch */*/*.ebuild| cut -d: -f1) | grep -v
> >> eutils
> >>
> >> Maybe they should be checked and a repoman warning should be added when
> >> an ebuild is using epatch without inheriting eutils directly, otherwise
> >> this problem could reappear if some other eclass no longer inherit it in
> >> the future :-/
> >
> > Maybe we should make eutils inheritance implicit so all ebuilds get epatch
> > and friends automatically. Is there really that much overhead? Or am I
> > missing something obvious?
>
> Do you mean in EAPI 5? We're already planning to include epatch, as part
> of the epatch_user thing.

I did. That's awesome, thanks.


--
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org

On Thu, 24 May 2012 00:02:37 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:
> I don't see how removing an inherit is breaking an eclass' API.

The way eclasses are defined, the eclasses it inherits are itself part
of its API. You can think of it using the lousy OO analogy that gave
eclasses their name: the (public) superclasses of a class are part of
its API.

--
Ciaran McCreesh

On Thu, 24 May 2012 14:02:05 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Thu, 24 May 2012 00:02:37 -0600
> Ryan Hill <dirtyepic@gentoo.org> wrote:
> > I don't see how removing an inherit is breaking an eclass' API.
>
> The way eclasses are defined, the eclasses it inherits are itself part
> of its API. You can think of it using the lousy OO analogy that gave
> eclasses their name: the (public) superclasses of a class are part of
> its API.

Like I said, technically it is. And that's terrible. Let's ignore it.


--
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org