Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

autotools.eclass no longer inherits eutils; check your ebuilds!

 

 

First page Previous page 1 2 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded


tetromino at gentoo

May 21, 2012, 10:46 AM

Post #1 of 27 (422 views)
Permalink
autotools.eclass no longer inherits eutils; check your ebuilds!

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.


pacho at gentoo

May 21, 2012, 12:04 PM

Post #2 of 27 (416 views)
Permalink
Re: autotools.eclass no longer inherits eutils; check your ebuilds! [In reply to]

El lun, 21-05-2012 a las 13:46 -0400, Alexandre Rostovtsev escribió:
> 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.
>
>
>

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 :-/
Attachments: signature.asc (0.19 KB)


zmedico at gentoo

May 21, 2012, 12:25 PM

Post #3 of 27 (408 views)
Permalink
Re: autotools.eclass no longer inherits eutils; check your ebuilds! [In reply to]

On 05/21/2012 12:04 PM, Pacho Ramos wrote:
> El lun, 21-05-2012 a las 13:46 -0400, Alexandre Rostovtsev escribió:
>> 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.
>>
>>
>>
>
> 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 :-/

Yeah, we have a similar check for inherit of prefix.eclass:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=b583812101f1156c553385effcd9dbee0b751087
--
Thanks,
Zac


vapier at gentoo

May 21, 2012, 12:39 PM

Post #4 of 27 (411 views)
Permalink
Re: autotools.eclass no longer inherits eutils; check your ebuilds! [In reply to]

On Monday 21 May 2012 15:04:44 Pacho Ramos wrote:
> El lun, 21-05-2012 a las 13:46 -0400, Alexandre Rostovtsev escribió:
> > 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!
>
> 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

this is what i was using:
find /usr/portage/*-* -name '*.ebuild' -exec grep -l '\<epatch\>' {} + | \
xargs grep -L inherit.*eutils

there's quite a number there :(

> 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 :-/

yeah, a repoman check would be a really good idea
-mike
Attachments: signature.asc (0.82 KB)


hwoarang at gentoo

May 21, 2012, 3:16 PM

Post #5 of 27 (413 views)
Permalink
Re: autotools.eclass no longer inherits eutils; check your ebuilds! [In reply to]

On 05/21/2012 06:46 PM, 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.
>
>
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.

--
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2


vapier at gentoo

May 21, 2012, 3:28 PM

Post #6 of 27 (408 views)
Permalink
Re: autotools.eclass no longer inherits eutils; check your ebuilds! [In reply to]

On Monday 21 May 2012 18:16:25 Markos Chandras 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.

you're assuming the breakage was intentional. i also wouldn't really describe
it as "significant", but that's just quibbling over an insignificant aspect.

but what's done is done. fix the ebuilds and move on.
-mike
Attachments: signature.asc (0.82 KB)


vivo75 at gmail

May 21, 2012, 4:01 PM

Post #7 of 27 (411 views)
Permalink
Re: autotools.eclass no longer inherits eutils; check your ebuilds! [In reply to]

2012/5/22 Mike Frysinger <vapier [at] gentoo>:
> On Monday 21 May 2012 18:16:25 Markos Chandras 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.
>
> you're assuming the breakage was intentional.  i also wouldn't really describe
> it as "significant", but that's just quibbling over an insignificant aspect.

It's intentional not to revert the change, it's significant because it
involve a number of significant packages like icu, vim and boost, some
of them already marked stable (from a fast grep from the one mentioned
in the previous posts).

> but what's done is done.  fix the ebuilds and move on.
> -mike

revert - fix the ebuilds - re-apply could work too, or since you're an
old and respected developer fix them yourself, the change is easy and
probably mantainers will understand.

Francesco R.


vapier at gentoo

May 21, 2012, 4:10 PM

Post #8 of 27 (412 views)
Permalink
Re: autotools.eclass no longer inherits eutils; check your ebuilds! [In reply to]

On Monday 21 May 2012 19:01:04 Francesco Riosa wrote:
> 2012/5/22 Mike Frysinger:
> > On Monday 21 May 2012 18:16:25 Markos Chandras 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.
> >
> > you're assuming the breakage was intentional. i also wouldn't really
> > describe it as "significant", but that's just quibbling over an
> > insignificant aspect.
>
> It's intentional not to revert the change, it's significant because it
> involve a number of significant packages like icu, vim and boost, some
> of them already marked stable (from a fast grep from the one mentioned
> in the previous posts).

you've identified the broke things. so fix them.
-mike
Attachments: signature.asc (0.82 KB)


vivo75 at gmail

May 21, 2012, 4:24 PM

Post #9 of 27 (399 views)
Permalink
Re: autotools.eclass no longer inherits eutils; check your ebuilds! [In reply to]

2012/5/22 Mike Frysinger <vapier [at] gentoo>:
> On Monday 21 May 2012 19:01:04 Francesco Riosa wrote:
>> 2012/5/22 Mike Frysinger:
>> > On Monday 21 May 2012 18:16:25 Markos Chandras 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.
>> >
>> > you're assuming the breakage was intentional.  i also wouldn't really
>> > describe it as "significant", but that's just quibbling over an
>> > insignificant aspect.
>>
>> It's intentional not to revert the change, it's significant because it
>> involve a number of significant packages like icu, vim and boost, some
>> of them already marked stable (from a fast grep from the one mentioned
>> in the previous posts).
>
> you've identified the broke things.  so fix them.
> -mike

wanna give me commit access for few hours?
I've already done mass changes to the tree when introducing
virtual/mysql seem something doable the same way.


vapier at gentoo

May 21, 2012, 4:37 PM

Post #10 of 27 (401 views)
Permalink
Re: autotools.eclass no longer inherits eutils; check your ebuilds! [In reply to]

On Monday 21 May 2012 19:24:27 Francesco Riosa wrote:
> 2012/5/22 Mike Frysinger:
> > On Monday 21 May 2012 19:01:04 Francesco Riosa wrote:
> >> 2012/5/22 Mike Frysinger:
> >> > On Monday 21 May 2012 18:16:25 Markos Chandras 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.
> >> >
> >> > you're assuming the breakage was intentional. i also wouldn't really
> >> > describe it as "significant", but that's just quibbling over an
> >> > insignificant aspect.
> >>
> >> It's intentional not to revert the change, it's significant because it
> >> involve a number of significant packages like icu, vim and boost, some
> >> of them already marked stable (from a fast grep from the one mentioned
> >> in the previous posts).
> >
> > you've identified the broke things. so fix them.
>
> wanna give me commit access for few hours?

just join as a dev and get it over with ;P

> I've already done mass changes to the tree when introducing
> virtual/mysql seem something doable the same way.

seems people have already fixed most (if not all) errors related to
autotools.eclass
-mike
Attachments: signature.asc (0.82 KB)


vivo75 at gmail

May 21, 2012, 4:55 PM

Post #11 of 27 (400 views)
Permalink
Re: autotools.eclass no longer inherits eutils; check your ebuilds! [In reply to]

2012/5/21 Mike Frysinger <vapier [at] gentoo>:
> On Monday 21 May 2012 19:24:27 Francesco Riosa wrote:
>> 2012/5/22 Mike Frysinger:
>> > On Monday 21 May 2012 19:01:04 Francesco Riosa wrote:
>> >> 2012/5/22 Mike Frysinger:
>> >> > On Monday 21 May 2012 18:16:25 Markos Chandras 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.
>> >> >
>> >> > you're assuming the breakage was intentional.  i also wouldn't really
>> >> > describe it as "significant", but that's just quibbling over an
>> >> > insignificant aspect.
>> >>
>> >> It's intentional not to revert the change, it's significant because it
>> >> involve a number of significant packages like icu, vim and boost, some
>> >> of them already marked stable (from a fast grep from the one mentioned
>> >> in the previous posts).
>> >
>> > you've identified the broke things.  so fix them.
>>
>> wanna give me commit access for few hours?
>
> just join as a dev and get it over with ;P

maybe gentoo will live better w/o my fat typeing hands :-P

>> I've already done mass changes to the tree when introducing
>> virtual/mysql seem something doable the same way.
>
> seems people have already fixed most (if not all) errors related to
> autotools.eclass

Seem to be the better outcome. If someone could fix the remaining
unfixed after x days that would be perfect, it's always unpleasant to
touch other devs ebuilds but sometimes is just the only thing to do
(replace with some philosophy mumble at pleasure;-)

good night and thanks for answering


arfrever.fta at gmail

May 21, 2012, 5:54 PM

Post #12 of 27 (408 views)
Permalink
Re: autotools.eclass no longer inherits eutils; check your ebuilds! [In reply to]

2012-05-22 01:01:04 Francesco Riosa napisał(a):
> 2012/5/22 Mike Frysinger <vapier [at] gentoo>:
> > On Monday 21 May 2012 18:16:25 Markos Chandras 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.
> >
> > you're assuming the breakage was intentional. i also wouldn't really describe
> > it as "significant", but that's just quibbling over an insignificant aspect.
>
> It's intentional not to revert the change, it's significant because it
> involve a number of significant packages like icu, vim and boost

These packages are not involved:

dev-libs/icu ebuilds do not inherit autotools.eclass.
An older ebuild (icu-4.8.1.1-r1.ebuild) inherits eutils.eclass only through versionator.eclass.

app-editors/vim ebuilds do not inherit autotools.eclass, and inherit vim.eclass,
which inherits eutils.eclass.

dev-libs/boost ebuilds do not inherit autotools.eclass, and inherit check-reqs.eclass,
flag-o-matic.eclass and versionator.eclass, which inherit eutils.eclass.

--
Arfrever Frehtes Taifersar Arahesis
Attachments: signature.asc (0.82 KB)


mgorny at gentoo

May 21, 2012, 10:53 PM

Post #13 of 27 (399 views)
Permalink
Re: autotools.eclass no longer inherits eutils; check your ebuilds! [In reply to]

On Mon, 21 May 2012 23:16:25 +0100
Markos Chandras <hwoarang [at] gentoo> wrote:

> On 05/21/2012 06:46 PM, 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.
> >
> >
> 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...

--
Best regards,
Michał Górny
Attachments: signature.asc (0.31 KB)


pacho at gentoo

May 22, 2012, 11:22 AM

Post #14 of 27 (402 views)
Permalink
Re: autotools.eclass no longer inherits eutils; check your ebuilds! [In reply to]

El lun, 21-05-2012 a las 12:25 -0700, Zac Medico escribió:
> On 05/21/2012 12:04 PM, Pacho Ramos wrote:
> > El lun, 21-05-2012 a las 13:46 -0400, Alexandre Rostovtsev escribió:
> >> 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.
> >>
> >>
> >>
> >
> > 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 :-/
>
> Yeah, we have a similar check for inherit of prefix.eclass:
>
> http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=b583812101f1156c553385effcd9dbee0b751087

Should we (I) open a bug report requesting that or this is enough as
report? Thanks :)
Attachments: signature.asc (0.19 KB)


zmedico at gentoo

May 22, 2012, 1:04 PM

Post #15 of 27 (398 views)
Permalink
Re: autotools.eclass no longer inherits eutils; check your ebuilds! [In reply to]

On 05/22/2012 11:22 AM, Pacho Ramos wrote:
> El lun, 21-05-2012 a las 12:25 -0700, Zac Medico escribió:
>> On 05/21/2012 12:04 PM, Pacho Ramos wrote:
>>> 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 :-/
>>
>> Yeah, we have a similar check for inherit of prefix.eclass:
>>
>> http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=b583812101f1156c553385effcd9dbee0b751087
>
> Should we (I) open a bug report requesting that or this is enough as
> report? Thanks :)

Done already:

https://bugs.gentoo.org/show_bug.cgi?id=417159
--
Thanks,
Zac


kensington at astralcloak

May 22, 2012, 1:39 PM

Post #16 of 27 (411 views)
Permalink
Re: autotools.eclass no longer inherits eutils; check your ebuilds! [In reply to]

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}.


pacho at gentoo

May 23, 2012, 1:04 AM

Post #17 of 27 (400 views)
Permalink
Re: Re: autotools.eclass no longer inherits eutils; check your ebuilds! [In reply to]

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)
Attachments: signature.asc (0.19 KB)


betelgeuse at gentoo

May 23, 2012, 1:28 AM

Post #18 of 27 (402 views)
Permalink
Re: autotools.eclass no longer inherits eutils; check your ebuilds! [In reply to]

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

Regards,
Petteri


hwoarang at gentoo

May 23, 2012, 2:31 AM

Post #19 of 27 (399 views)
Permalink
Re: Re: autotools.eclass no longer inherits eutils; check your ebuilds! [In reply to]

On Wed, May 23, 2012 at 9:04 AM, Pacho Ramos <pacho [at] gentoo> 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


pacho at gentoo

May 23, 2012, 4:00 AM

Post #20 of 27 (402 views)
Permalink
Re: Re: autotools.eclass no longer inherits eutils; check your ebuilds! [In reply to]

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 [at] gentoo> 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 :|
Attachments: signature.asc (0.19 KB)


xarthisius at gentoo

May 23, 2012, 4:26 AM

Post #21 of 27 (401 views)
Permalink
Re: Re: autotools.eclass no longer inherits eutils; check your ebuilds! [In reply to]

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 [at] gentoo> 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 :D

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

Cheers,
Kacper
Attachments: eclass_walker.py (2.14 KB)
  signature.asc (0.88 KB)


dirtyepic at gentoo

May 23, 2012, 11:02 PM

Post #22 of 27 (399 views)
Permalink
Re: autotools.eclass no longer inherits eutils; check your ebuilds! [In reply to]

On Wed, 23 May 2012 11:28:13 +0300
Petteri Räty <betelgeuse [at] gentoo> 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
Attachments: signature.asc (0.19 KB)


zmedico at gentoo

May 23, 2012, 11:09 PM

Post #23 of 27 (400 views)
Permalink
Re: Re: autotools.eclass no longer inherits eutils; check your ebuilds! [In reply to]

On 05/23/2012 11:11 PM, Ryan Hill wrote:
> On Mon, 21 May 2012 21:04:44 +0200
> Pacho Ramos <pacho [at] gentoo> 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


dirtyepic at gentoo

May 23, 2012, 11:11 PM

Post #24 of 27 (397 views)
Permalink
Re: autotools.eclass no longer inherits eutils; check your ebuilds! [In reply to]

On Mon, 21 May 2012 21:04:44 +0200
Pacho Ramos <pacho [at] gentoo> 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
Attachments: signature.asc (0.19 KB)


dirtyepic at gentoo

May 23, 2012, 11:29 PM

Post #25 of 27 (397 views)
Permalink
Re: autotools.eclass no longer inherits eutils; check your ebuilds! [In reply to]

On Wed, 23 May 2012 23:09:14 -0700
Zac Medico <zmedico [at] gentoo> wrote:

> On 05/23/2012 11:11 PM, Ryan Hill wrote:
> > On Mon, 21 May 2012 21:04:44 +0200
> > Pacho Ramos <pacho [at] gentoo> 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
Attachments: signature.asc (0.19 KB)

First page Previous page 1 2 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.