Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided

[Paul Bredbury]

>    if built_with_use sci-libs/lapack-atlas ifc; then
>        ...
>        die "Inconsistent Fortran compilers"
>    fi

My challenge was to find an example of an ebuild which is *not*
installed (taking into account package.provided, thanks to my patch) but
which should have *positive* "built_with_use" functions. I'm still
waiting.

If the package is installed through package.provided, then I agree with
the *current* Portage behaviour of assuming that all USE flags are on.
Ya can't blame me for that. It's currently the only sensible choice.
(Funnily enough, no-one has suggested dying as an option for this).

> Does conflating two conditions to one output make sense?

Yes, because you are ignoring the fact that condition 2 *depends* on
condition 1. If a package hasn't been built, then it hasn't been built
with any USE flag. I've stated this several times now, and it keeps
being asked as if it's a new question, always with a question, never
something to challenge it. To turn it around in the hope that it is
clearer: How can you expect a package to have been built *with* a USE
flag when it hasn't been *built*?

If you think that what I'm saying is false, then *challenge* it.

> But they do expect that if "built_with_use app-foo/bar shiney" returns
> FALSE, then app-foo/bar was built with the "shiney" USE flag unset.

They are wrong. They are ignoring the perfectly valid situation that bar
wasn't built, whilst expecting a Boolean result anyway. But, explain it
to them, and they will understand that the program is answering as best
as it can. Try to explain to them why a program instead falls over in a
big heap, and you will probably have difficulty in getting paid for your
programming work. That's the big difference.

There is a big difference between a program answering as best as it can
(without going into the currently-impossible arena of "artificial
intelligence"), and falling over in a big heap. Oh I'm sorry, I mean
raising an exception. Like an exception is so much more useful than
falling over in a big heap.

> Insufficient information is an error condition.

OK, then Portage is horribly wrong in its current behaviour, because its
built_with_use and has_version functions don't even pretend to look at
package.provided, so they don't have insufficent information, so they
should *always* die immediately. Correct? See how logic can look stupid
when stated simplistically?

> Paranoia much?

I'm trying to teach logic to schoolkids who are using the argument that
I'm outnumbered 5 to 1, therefore I'm wrong. This is a really crappy
situation to be in, for anyone who wants to improve Portage rather than
just be called a dick by schoolkids.

> And in other circumstances?

Tricky. I'm not going to commit to a definite answer to such a vague
question, because it depends. Python has the option of returning None,
as well as a value, which can be much more elegantly handled than an
exception. Dying in an ebuild, is of course a *last* resort.

There's also quake*1*-data, although it's practically identical to
quake2-data. It's just a meaningless bit of fate that this bug hits
something as inconsequential as an old game - it's still a Portage bug,
waiting to bite *any* package. No-one really cares about the bug right
now, because it's only games that are affected.

Don't stop now, I might end up enjoying this after all.
-- 
gentoo-portage-dev@g.o mailing list