[gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!
On Mon, 21 May 2012 21:04:44 +0200 Pacho Ramos pa...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!
On 05/23/2012 11:11 PM, Ryan Hill wrote: On Mon, 21 May 2012 21:04:44 +0200 Pacho Ramos pa...@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
[gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!
On Wed, 23 May 2012 23:09:14 -0700 Zac Medico zmed...@gentoo.org wrote: On 05/23/2012 11:11 PM, Ryan Hill wrote: On Mon, 21 May 2012 21:04:44 +0200 Pacho Ramos pa...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!
On Thu, 24 May 2012 00:02:37 -0600 Ryan Hill dirtye...@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 signature.asc Description: PGP signature
[gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!
On Thu, 24 May 2012 14:02:05 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 24 May 2012 00:02:37 -0600 Ryan Hill dirtye...@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. :D -- fonts, gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!
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.133r2=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)
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!
On Wed, May 23, 2012 at 9:04 AM, Pacho Ramos pa...@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.133r2=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
Re: [gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!
El mié, 23-05-2012 a las 10:31 +0100, Markos Chandras escribió:
On Wed, May 23, 2012 at 9:04 AM, Pacho Ramos pa...@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.133r2=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 :|
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!
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 pa...@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.133r2=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
#!/usr/bin/env python
import re
import os
import argparse
class DirectoryWalker:
# a forward iterator that traverses a directory tree
def __init__(self, directory):
self.stack = [directory]
self.files = []
self.index = 0
def __getitem__(self, index):
while 1:
try:
file = self.files[self.index]
self.index = self.index + 1
except IndexError:
# pop next directory from stack
self.directory = self.stack.pop()
self.files = os.listdir(self.directory)
self.index = 0
else:
# got a filename
fullname = os.path.join(self.directory, file)
if os.path.isdir(fullname) and not os.path.islink(fullname):
self.stack.append(fullname)
return fullname
usage = usage: %prog [options] DIRECTORY
parser = argparse.ArgumentParser()
parser.add_argument(-e, nargs=1, default=[user],
help=Name of the eclass to test, e.g. 'user')
parser.add_argument(-p, nargs=1, default=[/usr/portage],
help=Directory where eclass resides, e.g. PORTDIR)
parser.add_argument(directory, nargs=1,
help=Directory with ebuilds to run tests )
args = parser.parse_args()
is_ebuild = re.compile('\.ebuild$')
ebuilds = filter(is_ebuild.search, DirectoryWalker(args.directory[0]))
re_func = re.compile(FUNCTION).search # TODO: improve me
fname = open('%s/eclass/%s.eclass'% (args.p[0], args.e[0]))
funcs = [func.split()[-1].strip()
for func in filter(re_func, fname.readlines())]
fname.close()
# Listen carefully, I shall speak it only once
regexps = {func: re.compile(func).search for func in funcs}
re_inher = re.compile(^inherit.*%s% args.e[0]).match
for ebuild in ebuilds:
fname = open(ebuild,'r')
lines = fname.readlines()
fname.close()
uses_function = any([len(filter(regexps[key], lines))
for key in regexps.keys()])
uses_eclass = len(filter(re_inher, lines))
if uses_function and not uses_eclass:
print(%s should inherit %s.eclass % (ebuild, args.e[0]))
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!
On Wed, 23 May 2012 11:28:13 +0300 Petteri Räty betelge...@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/2008-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 signature.asc Description: PGP signature
[gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!
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.133r2=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}.
