On Mon, 17 Sep 2012 00:58:02 -0700
"Gregory M. Turner" <g...@malth.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.
