Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided
On Tue, 08 Aug 2006 00:54:29 +0100, Paul Bredbury [EMAIL PROTECTED] wrote: 3. package has not been built. (?) The answer is False, not unknown, as I keep saying. You keep trying to reason based on a function name (built_with_use). From a litteral english point of view, i would agree with you that a package which was not built at all is not built with any particular flag. But, see, this is just a function name, and that's not what defines its expected semantics. There is nothing one can prove by logic here¹, but just a choice to make. The only thing which matters is what devs think is the most convenient for their needs, and it is clear from this discussion that they all prefer a function which is only defined for installed packages (and dies when missused, so that missuses are detected and fixed). Maybe a better name would have been: was_the_installed_package_foo_built_with_the_flag_bar_comma_where_foo_is_first_argument_and_bar_the_second_one_question_mark ...but that's a bit too long, and this kind of details should rather go to the documentation. There, you'll meet conditional probability. If A is False, then the probability of B, given that B *depends* on A, is zero. Take probabilities of a coin flip, apply them to a dice, and you can prove it always falls on tails, since it can't fall on heads. Or maybe it's the opposite, oh well... Again, reasoning out of the definition domain gives nothing meaningful. For build_with_use, it has been decided that the definition domain would be installed packages. Deal with it. ¹ the only thing one really bored could try to prove is that the actual implementation of the function fits its expected semantics. But that's a different topic. -- TGL. -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided
On Sun, 2006-08-06 at 22:08 +0100, Paul Bredbury wrote: Other cases would want it to return TRUE. Got an example of those? I expect to be able to show that they're incorrect. Sorry to keep this alive. Example: subversion.eclass has if built_with_use dev-util/subversion nowebdav; then die need webdav support in subversion ... Clearly, where an ebuild requires that a package be merged *without* a USE flag set, a FALSE return from built_with_use is expected to indicate that that package was merged with that USE flag unset. Looking at this logically, you're interpreting built_with_use as the Russell definite designator: built_with_use (A, Fl) := Fl set_on (i P. P matches A) == Ex P. (All P'. (P' matches A = P' = P) ^ Fl set_on P) where A denotes an atom, Fl a flag, P, P' a package. Yes, the Russell definite designator has value FALSE if it lacks a referent; however there is no need for built_with_use to behave as the definite designator, since we have a trinary logic (TRUE, FALSE, die) available. The big problem with the Russell definite designator is that it is not self-dual under negation (and its dual under negation is not useful); a trinary definite designator /is/ self-dual. (That is, built_with_use app-foo/bar shiney is equivalent to ! built_with_use app-foo/bar -shiney. Which is what ebuild authors want.) HTH, Ed -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided
if built_with_use dev-util/subversion nowebdav; then So Portage needs an end to USE flags whose first 2 characters are 'no' day, in order to keep its complexity bearable. Which is already known, in the dev manual (whose URL I'm too lazy to look up right now). The big problem with the Russell definite designator is that it is not self-dual under negation (and its dual under negation is not useful); a trinary definite designator /is/ self-dual. That's useful info in a school exam. The flaw is, this is not a maths quiz set by a university professor (I went through all that at uni ~13 years ago). It's a computer program. Run by people. Who expect it to make sense. These people couldn't care less whether it's self-dual under negation. What they care about is whether it gives the right answer, or the opposite of the right answer (or equally worse, falls over in a big heap) when the right answer should be obvious to it (which is what my patches do, although this fact has so far been glossed over). The attractive elegance of logical dualism is *not* an excuse for programs falling over in a big heap when the correct answer in certain circumstances (bug #139693) is obvious. -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided
Edward Catmur wrote: 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. First, having users poke around in vdb is a very bad idea. Doing the wrong thing in there can cause all kinds of weird b0rkage. Second, does portage even consult vdb for a package in package.provided? package.provided was created to *replace* the act of creating a dummy vdb entry (I think that's how it was done, anyway) to fool portage into thinking a package was installed. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided
Checking for a package that isn't either a direct or indirect dependency is plain wrong. package.provided is not supported - it's the users fault, if he insists to sidestep Portage. There is no valid case for your construct. With regards to QA, it wouldn't be wrong to have a better solution, but given that built_with_use() is itself only a workaroud for still not having use dependencies, it's a bit pointless. Carsten pgpIcKouSDHXT.pgp Description: PGP signature
Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided
On Mon, 2006-08-07 at 23:21 +0100, Paul Bredbury wrote: Ah... that was an example of a package that isn't installed that *shouldn't* have *negative* return from built_with_use. Wrong. Substitute positive for negative, and your sentence makes sense, but invalidates your point. Ah, the argument by assertion. Equally, it hasn't been built *without* that USE flag. How does that invalidate the conclusion that the package hasn't been built? ... It's not guessing. It's sensible behaviour. It's not random. it's logical, it's consistent, and it makes sense. 1. package has been built with USE flag. (True) 2. package has been built without USE flag. (False) 3. package has not been built. (?) There is no reason to conflate 3 with either 1 or 2; 1 and 2 are symmetrical. vdb is preferred over package.provided. Of course. It has a higher priority, and is consulted first. Your point is? I was addressing your previous point. Which you failed to include in your most recent reply. The bug I'm referring to is bug #139842. Which is currently marked wontfix, and contains 2 patches which fix the bug. The patch to portageq (has_version) looks good. The built_with_use patch - well, built_with_use has already been fixed to die when the package doesn't exist. Ed -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided
3. package has not been built. (?) The answer is False, not unknown, as I keep saying. If you're still at uni, go take a course in Probability. There, you'll meet conditional probability. If A is False, then the probability of B, given that B *depends* on A, is zero. -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided
Paul Bredbury wrote: Hi, I was directed to this list after my Portage patches were rejected. I'm hoping that someone *other* than the rejecter will look at the bug, and: See it as a valid bug, reopen it, and take SpanKY's keyboard away so he can't reject it again. The bug is: http://bugs.gentoo.org/show_bug.cgi?id=139842 Executive Summary: built_with_use returns the opposite answer to what it should, when the package referred to is not installed. I provided patches to stop that broken behaviour. People decided to talk about some mystical third state which doesn't exist in Boolean logic, and ended up convinced that black is white. And then proceeded to get themselves run over at the next Zebra crossing. As I said on irc, you need to chill out; being a dick here won't help you anymore than it did there. -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided
There is a third option. Reporting an error. But it is not an error. The answer is known to be False, through the application of logic. -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided
Paul Bredbury wrote: But it is not an error. The answer is known to be False, through the application of logic. No. Let's get really sophisticated and do the 'application of logic' step. There is a function built_with_use(). That function reports whether something was built with or without a specific USE flag. The sentence above includes the fragment 'was built with or without'. So it was built. Uh, oh, but it wasn't built!!?!? - Error Really. Go find a mathematician and discuss this matter with him. Tell him what you told me, and he will slap you with a large frying pan. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided
Paul Bredbury wrote: There is a third option. Reporting an error. But it is not an error. The answer is known to be False, through the application of logic. There are really 3 states here Either you have enough information to prove something true; OR you have enough information to prove something false; OR you don't have enough information to prove anything. In this case there is no USE information available for PROVIDE'd packages, which was your original complaint. Just because you can't prove that built_with_use provided pkg foo == true doesn't mean you have enough information to prove that built_with_use provided pkg foo == false Becauase there IS a third state, it's call the we don't have enough information to prove anything state, which is what we have here. The package may very well work fine, the package may not, there is no way to tell. Thats our whole point. Hell, SpanKY already filed the real bug, which is requesting support for provided packages so that you can provide a package with USE flags set, therefore solving this whole lack of information issue. Because you see, that is what the real issue is, a lack of information. -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided
and you have failed thus far. The only other things I could do are start muttering about good programming practices, and how to write correct and reliable programs. Oh well, I did try, but I'll drop the subject now. Remember: Every time that an ebuild dies for this reason, and the user wonders why stupid Portage couldn't just go ahead with the obvious answer, it annoys the user. -- gentoo-portage-dev@gentoo.org mailing list
