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: Ryan Hill <dirtyepic@g.o>
Subject: Re: autotools.eclass no longer inherits eutils; check your ebuilds!
Date: Thu, 24 May 2012 00:02:37 -0600
On Wed, 23 May 2012 11:28:13 +0300
Petteri Räty <betelgeuse@g.o> 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
Attachment:
signature.asc (PGP signature)
Replies:
Re: Re: autotools.eclass no longer inherits eutils; check your ebuilds!
-- Ciaran McCreesh
References:
autotools.eclass no longer inherits eutils; check your ebuilds!
-- Alexandre Rostovtsev
Re: autotools.eclass no longer inherits eutils; check your ebuilds!
-- Markos Chandras
Re: autotools.eclass no longer inherits eutils; check your ebuilds!
-- Michał Górny
Re: autotools.eclass no longer inherits eutils; check your ebuilds!
-- Petteri Räty
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: autotools.eclass no longer inherits eutils; check your ebuilds!
Next by thread:
Re: Re: autotools.eclass no longer inherits eutils; check your ebuilds!
Previous by date:
Re: enhancement for doicon/newicon in eutils.eclass
Next by date:
Re: Portage Git migration - clean cut or git-cvsserver


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.