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
