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

[Edward Catmur]

On Mon, 2006-08-07 at 15:27 +0100, Paul Bredbury wrote:
> >    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.
Ah... that was an example of a package that isn't installed that
*shouldn't* have *negative* return from built_with_use.

Of course, ebuild authors shouldn't be calling built_with_use on
non-installed packages anyway (which is to say, they should restrict the
atom argument of built_with_use to items in USE-flattened DEPEND).
Dying is a sensible response.

> 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).
I would. Pending a proper resolution (USE data in package.provided),
users can set USE in vdb.

> > 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*?
Equally, it hasn't been built *without* that USE flag. Non-self-dual, as
I said.

> If you think that what I'm saying is false, then *challenge* it.
A true return value indicates the package was built with the USE flag
set; a false return value that it was built with the USE flag unset.
Tertium datur: die. ("mori"?)

> > 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.
Not valid. built_with_use should not be called on non-installed atoms.

> But, explain it
> to them, and they will understand that the program is answering as best
> as it can.
Guessing in exception situations creates bugs.

> 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.
None of us are getting paid. The "them" in question are fellow
developers.

> 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.
ebuild.sh exceptions have an error message and call stack. Easily enough
to diagnose the fault.

> > 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?
vdb is preferred over package.provided.

> > 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.
The complement to the democratic fallacy is the autocratic fallacy.
Which is more likely to be at work here?

> > 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.
Absolutely not. When you get lost, the sooner you stop and ask for
directions the less likely you are to get mugged.

> 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.
Je ne comprends pas.

> Don't stop now, I might end up enjoying this after all.
What a pity.

Ed

-- 
gentoo-portage-dev@g.o mailing list