[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
From:       Pacho Ramos <pacho () gentoo ! org>
Date:       2012-09-20 17:52:11
Message-ID: 1348163531.27524.33.camel () belkin4
[Download RAW message or body]


El jue, 20-09-2012 a las 03:33 -0400, Alexandre Rostovtsev escribió:
> On Thu, 2012-09-20 at 08:43 +0200, Pacho Ramos wrote:
> > El jue, 20-09-2012 a las 02:14 -0400, Alexandre Rostovtsev escribió:
> > > Revised to use a separate variable for the name of the flag instead of
> > > reading IUSE, as suggested by Ciaran McCreesh. As a result of this
> > > change, vala.eclass now defaults to assuming that vala support is
> > > optional (which is the case in an overwhelming majority of ebuilds that
> > > would want to use this eclass).
> > 
> > Sorry but, why even in_iuse function from eutils.eclass cannot be used?
> > If that is really not allowed, why we have that function in
> > eutils.eclass?
> > 
> > There are lots of cases in eclasses relying on things like original
> > suggested way or in_iuse from eutils.eclass and would like to clarify
> > things before going with a more complex way than original.
> > 
> > I already know Ciaran's opinion on this, but would like to know more
> > opinion and, most important, is this is really allowed or not and, if
> > not, we should try to migrate current eclasses to the "fixed" way if
> > there is really a way providing similar function.
> 
> A fair number of existing eclasses and ebuilds rely on being able to
> read IUSE, whether directly or via in_iuse/use_if_iuse, so it evidently
> works with current versions of portage and bash (otherwise users would
> be complaining). But technically, these ebuilds/eclasses are relying on
> unspecified behavior. There is no immediate pressure to change them -
> after all, they work fine at the moment, and in the case of ebuilds,
> avoiding IUSE would probably require changes to the ebuild's API.
> 

The problem is that I suspect that, maybe, this behavior was present and
supported even in eapi0 (when, if I don't misremember, portage behavior
was taken with small modifications as start point for newer eapis) then,
maybe, this is simply a problem of forgetting to document this behavior
that looks to work and be supported for all EAPIs for ages, making the
need of waiting for eapi6 to use this useless and a nonsense.


> But given that we are already making a change to vala_src_prepare's
> default behavior, it makes sense to ensure that the change in a way that
> respects the pms. Although it will almost certainly provide no practical
> benefits, it is still good style.
> 

The problem is that there is no gain as it moves from autodetecting USE
to need to manually review ebuild and add another variable to specify it
manually :|, it clearly has cons over using "automatic" way to fix an
unspecified behavior that could be fixed simply "specifying" it as that
behavior is there for ages, is used in the tree for a long time and we
are already relying on it for many eclasses/ebuilds. The other option
would be to move all of them to another way alternative way to, once
eapi6 is approved, revert them to previous situation, causing us to lose
a lot of time with no gain.


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]