Re: [gentoo-dev] Re: [PATCH] eutils: Warn on built_with_use usage

[Ralph Sennhauser]

On Mon, 17 Sep 2012 00:58:02 -0700
"Gregory M. Turner" <gmt@×××××.us> wrote:

>
> > My main focus here is switching built_with_use to actively nagging
>  > people to stop using it; this includes nagging EAPI0/1 users of it.
> > Sans the implementation details, anyone got complaints with the
> > intent?
>
> I have a concern about it, yes.  But, maybe there's a good answer to
> my concern, so please consider this a friendly ebuild development
> question disguised as a complaint :)
>
> Unless I'm missing something, it seems that once we deprive the
> ebuild developer of this feature, there is no simple, supported way
> to retrieve the information except to depend on it.
>
> The issue is that calculating dependencies is not the only reason we
> might want to know if a package was built with a particular USE-flag,
> and if we get rid of built_with_use, we literally cut ourselves off
> from retrieving this information in any officially sanctioned way
> (except to DEPEND on it, which may not be semantically correct).
>
> I can think of all kinds of legitimate reasons we might want to know
> if the installed such-and-such package was built with so-and-so
> use-flags without depending on it.  i.e.:
>
>   o if the current gcc falls within a certain range of version
>     numbers and was built with graphite, we are going to trigger
>     a compiler bug.  Suppose that there is no graphite support
>     or dependency in ${P}, and that we can apply a patch which will
> work around the bug, but at a performance cost in ${P} we'd rather not
>     pay unless we have to.
>
>   o We need to modify a Makefile based on how a package we
>     BDEPEND on was built -- but suppose there is no BDEPEND
>     /limitation/ to enforce -- in other words, either way, our package
>     will build, and there is no correlating reverse dependency to
> worry about at runtime.
>
> Such needs are fairly unusual, but they do come up in real life.
>
> My concern is that this will lead to people doing things like:
>
>   o cut-pasting the old implementation of built_with_use into ebuilds,
>     -- but that implementation will break if the portage database
> layout changes
>
>   o creating bogus one-off use-flags as a way of performing these
> queries (and, thanks to the upcoming requirement that USE flags
>     always appear in IUSE, exposing those flags to the end-user,
> perhaps with some confusing description like "whether such-and-such
> was built with so-and-so").
>
>   o creating BDEPENDs of -- and sketchy parsers for -- portage-utils
> or similar suites, just to ask this question.
>
> Admittedly, it's hard to prevent people from doing
>
>    built-with-use foo/bar baz || die "${P} needs foo/bar with baz"
>
> since, once upon a time, that was SOP, and we'd have to parse the
> bash code or something to qa warn for it automatically.
>
> But any number of similar prohibitions are simply documented in the
> developer handbook, including this one.
>
> Am I missing something, here?  I kinda think we should go the
> opposite direction and un-deprecate the API.  It seems like we are
> cutting off our nose to spite our face here.
>
> -gmt
>

has_version foo/bar[baz] can be used in EAPI 2 and later.