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
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
On Mon, 2006-08-07 at 22:48 +0100, Paul Bredbury wrote: > Devs here seem to think that returning a logically wrong value is OK, as > long as it's returned *quickly* and *simply*. Absolutely. Worse is better. Ed -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] use.force and package.use.force (bug #142853)
Andrew Gaffney wrote: Flag shouldn't be forced, period imo. I could not agree with this more. I've been watching this whole thread wondering when certain people were gonna see how dumb this idea actually is (no offense...I've backed my fair share of dumb ideas). It's a crappy alternative for Alec's IUSE defaults. Can you elaborate on how default use flags relate to forcing/masking flags? I'm just too dumb to see the relation, other than they're both about use flags... That being said, I would have liked this feature already 1.5 years ago. If we had had use.force at that time, we didn't have to introduce a has_multilib_profile function and mask the multilib use flag which lead to much confusion amongst the users, because up to 2004.3 we told them that they would be unable to get anything 32bit running without that flag and then suddenly they all saw (-multilib) in their emerge -pv output. We could have simply continued to use that flag, forcing it on multilib-enabled profiles and masking it on the no-multilib ones. Other examples are probably 'selinux' on selinux-profiles, 'pic' on hardened (not sure about that one), and ip28 on ip28 profiles (as spb pointed out on IRC). You may argue that there are not many USE flags, but we have a prove that the concept would be useful, and the work's basically already been done, so let's use it. I know there will be cases where someone will want to force a flag on for one (or more) package but there will be other packages that forcing the same flag on is undesireable. Unless use.force can be done per-package, it will always be a very crappy alternative to IUSE defaults. Even then, it should still *act* like IUSE defaults (stuck somewhere in the USE stacking order and "easily" overridden). I only see this useful for local USE flags which you want to force, like e.g. ip28. That being said, Zac's patch already handles that case, AFAIK. -- 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
On Monday 07 August 2006 23:39, Paul Bredbury wrote: > That's what SpanKY said. Then he "fixed" quake2-data in bug #139693 to > include has_version, simply to hide the broken behaviour of > built_with_use. > So, would you have fixed the bug differently, or are you using the word > "plain" in the hope that you're right without having looked at the bug? Well, I don't have the time to read all the discussions and read only the last few replies of this one. Looking at the ebuild, I'd argue quake2-demodata and quake2-data should block each other, but I might be wrong, since I don't know the package. The word "plain" - drop it, it's still wrong. :) Carsten pgpjrPSsrRMf6.pgp Description: PGP signature
Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided
> 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.
> Equally, it hasn't been built *without* that USE flag. Non-self-dual,
as
> I said.
So *what* if it's "non-self-dual"? Who cares in the slightest whether
it's "non-self-dual"? How does that invalidate the conclusion that the
package hasn't been built? Repeating these claims with nothing to back
them up, doesn't make them true.
> Tertium datur: die. ("mori"?)
Any moron can quote Latin from a textbook in the hope of appearing
clever (bonus points if you fail to form a complete sentence, and end in
a question mark to create an aura of ambiguity). Challenge my logic in
*English*.
> Guessing in exception situations creates bugs.
It's not "guessing". It's sensible behaviour. It's not random. it's
logical, it's consistent, and it makes sense.
> None of us are getting paid. The "them" in question are fellow
> developers.
I know. Doesn't turn "falling over in a big heap" from a bad result into
a good result.
> vdb is preferred over package.provided.
Of course. It has a higher priority, and is consulted first. Your point
is?
> Je ne comprends pas.
The bug I'm referring to is bug #139842. Which is currently marked
"wontfix", and contains 2 patches which fix the bug.
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided
> Second, does portage even consult vdb for a package in > package.provided? It *should*, especially in has_version, otherwise it's ignoring very relevant information. See the patches on bug #139842. Devs here seem to think that returning a logically wrong value is OK, as long as it's returned *quickly* and *simply*. -- 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. That's what SpanKY said. Then he "fixed" quake2-data in bug #139693 to include has_version, simply to hide the broken behaviour of built_with_use. So, would you have fixed the bug differently, or are you using the word "plain" in the hope that you're right without having looked at the bug? -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] use.force and package.use.force (bug #142853)
On Mon, 7 Aug 2006 14:14:11 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: > On Mon, Aug 07, 2006 at 01:13:34PM -0700, Zac Medico wrote: > > Brian Harring wrote: > > > Semantics of USE=-gtk not working on a package that has gtk > > > forced doesn't sound all that nice btw; > > > > Which is why the flag shouldn't be forced unless it's almost > > certain that the flag shouldn't be disabled. The gtk flag might > > not ever fall into that category, but something like cxx might > > (nocxx inverted). > > Flag shouldn't be forced, period imo. What about masked flags, should those exist? Because use.force and use.mask are pretty much the same: accounting for configurations (=profiles) where support for a flag is not available/not optional (IIRC one example was USE=hardened on hardened profiles, solar may correct me here). So if you want to deny one, you should deny both. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] use.force and package.use.force (bug #142853)
Brian Harring wrote: On Mon, Aug 07, 2006 at 01:13:34PM -0700, Zac Medico wrote: Brian Harring wrote: Semantics of USE=-gtk not working on a package that has gtk forced doesn't sound all that nice btw; Which is why the flag shouldn't be forced unless it's almost certain that the flag shouldn't be disabled. The gtk flag might not ever fall into that category, but something like cxx might (nocxx inverted). Flag shouldn't be forced, period imo. I could not agree with this more. I've been watching this whole thread wondering when certain people were gonna see how dumb this idea actually is (no offense...I've backed my fair share of dumb ideas). It's a crappy alternative for Alec's IUSE defaults. I know there will be cases where someone will want to force a flag on for one (or more) package but there will be other packages that forcing the same flag on is undesireable. Unless use.force can be done per-package, it will always be a very crappy alternative to IUSE defaults. Even then, it should still *act* like IUSE defaults (stuck somewhere in the USE stacking order and "easily" overridden). -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] use.force and package.use.force (bug #142853)
On Mon, Aug 07, 2006 at 01:13:34PM -0700, Zac Medico wrote: > Brian Harring wrote: > > Semantics of USE=-gtk not working on a package that has gtk forced > > doesn't sound all that nice btw; > > Which is why the flag shouldn't be forced unless it's almost > certain that the flag shouldn't be disabled. The gtk flag might not > ever fall into that category, but something like cxx might (nocxx > inverted). Flag shouldn't be forced, period imo. A default use configuration of a package is fine, but it should be mutable via the normal methods imo (potential exception being USE="-*" handling since that one is the oddball). Again, this should involve the dev community (both package.use.mask implementation and use.force)- it needs a fair amount of thought put into it, and agreement from folks over it- otherwise y'all wind up reinventing the wheel without actually picking up the relevant points from past discussions of this. Upshot of involving more folks in the discussion, people would point out things like "how are you going to represent this in emerge -vp output?" Cause... package.use.mask ain't represented in any shape/form right now :) ~harring pgpwHI0mBmYnG.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] use.force and package.use.force (bug #142853)
On Mon, Aug 07, 2006 at 03:52:35PM +, Alec Warner wrote: > > >> Brian, default USE in IUSE is not a backwards compatable change and this > >> is easier ;) > > > > An EAPI bump is pretty simple from where I'm sitting, and implementing > > it isn't all that hard. > > > > Meanwhile, the question should be "which is desirable", not "which can > > I glue in quickest" ;) > > > > ~harring > > This is reality, not the ideal; Was also what devs wanted, last time this was discussed on dev ml from what I recall. Meanwhile, this is not an 'ideal' if you think it through. The request is effectively per node use configuration mangling of the default state- reality being that package.use _already_ exists, and shoehorning which ever is implemented relies on the same bits. > and implementing a dep resolver like you > wanted IS hard, thats why it took you and stubbs a ton of time > figuring out what you wanted and then implementing it. Way off base here. See the paragraph above- further, while this involves the resolver, it's not actually a resolver mod. The design jstubbs and I kicked around (what is now in pkgcore) goes several steps beyond what actually is needed- said design break config instances down and binds it per pkg instance- that's more of an issue for supporting actual use deps though, although said design isn't a requirement; paludis supports it via using (effectively) a construct similar to portages config class. We (moreso me on this one) wanted a format agnostic resolver- the design/implementation reflects that choice, but doesn't mean that route is the only way (again, paludis is closer to portage in this regard- it's doable). Meanwhile, we're talking about default iuse here; totally unrelated subjects. Resolver actually doesn't have a helluva lot to do with this in portages design- at the very least the view that default IUSE requires a "dep resolver like you wanted" (bit vague) pretty much has no relevance, and indicates you're a bit confused on this (especially since the critique is leveled at default IUSE while ignoring that use.force is no different). See zacs patch- both use.force and default IUSE require going back to the config obj at some point- the difference is contained in config; finally, EAPI protection should work fine for it- prefix has been relying on that already for a long ass time now. ~harring pgpKK0pBKVTcq.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] use.force and package.use.force (bug #142853)
Zac Medico wrote:
> Alec Warner wrote:
>>> Zac Medico wrote:
>>>
Users can unforce them via
/etc/portage/profile/{use.force,package.use.force} in the usual "-flag"
way.
>>> Why new files? Why isn't this just pushed into the use stacking order
>>> over-ridable by the user (default USE flags, and not forcing)?
>
> Much like use.mask, which is for flags that almost certainly should _not_ be
> enabled, use.force is for flags that almost certainly _should_ enable.
>
>>> Then they can over-ride it in package.use just like they do now?
>
> Again, it's akin to use.mask, and protects the user from accidentally doing
> something that they almost certainly shouldn't do (though they have the
> option to override it if absolutely necessary).
>
> Zac
hrm, so not default use flags then.
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] use.force and package.use.force (bug #142853)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Harring wrote: > Semantics of USE=-gtk not working on a package that has gtk forced > doesn't sound all that nice btw; Which is why the flag shouldn't be forced unless it's almost certain that the flag shouldn't be disabled. The gtk flag might not ever fall into that category, but something like cxx might (nocxx inverted). Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE157t/ejvha5XGaMRAncBAJ9QNHCEUJOFdwsZb40cp5pUqaouYQCfZZR1 N/n/XsXWO/gl8Ijw6Q+miXE= =uIuU -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] use.force and package.use.force (bug #142853)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alec Warner wrote:
> Zac Medico wrote:
>
>> Users can unforce them via
>> /etc/portage/profile/{use.force,package.use.force} in the usual "-flag" way.
>
> Why new files? Why isn't this just pushed into the use stacking order
> over-ridable by the user (default USE flags, and not forcing)?
Much like use.mask, which is for flags that almost certainly should _not_ be
enabled, use.force is for flags that almost certainly _should_ enable.
> Then they can over-ride it in package.use just like they do now?
Again, it's akin to use.mask, and protects the user from accidentally doing
something that they almost certainly shouldn't do (though they have the option
to override it if absolutely necessary).
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFE153K/ejvha5XGaMRAoGnAJ9sCh9OMu064tLwScuyQdBvbHiwKwCg3RBv
4feX6Eg2jZen/TiQfhdzr6o=
=j/9F
-END PGP SIGNATURE-
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] use.force and package.use.force (bug #142853)
>> Brian, default USE in IUSE is not a backwards compatable change and this >> is easier ;) > > An EAPI bump is pretty simple from where I'm sitting, and implementing > it isn't all that hard. > > Meanwhile, the question should be "which is desirable", not "which can > I glue in quickest" ;) > > ~harring This is reality, not the ideal; and implementing a dep resolver like you wanted IS hard, thats why it took you and stubbs a ton of time figuring out what you wanted and then implementing it. -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] use.force and package.use.force (bug #142853)
On Mon, Aug 07, 2006 at 10:01:12AM +, Alec Warner wrote:
> Zac Medico wrote:
>
> >Users can unforce them via
> >/etc/portage/profile/{use.force,package.use.force} in the usual "-flag" way.
>
> Why new files? Why isn't this just pushed into the use stacking order
> over-ridable by the user (default USE flags, and not forcing)?
>
> Then they can over-ride it in package.use just like they do now?
Semantics of USE=-gtk not working on a package that has gtk forced
doesn't sound all that nice btw; if it's conditional yet the user has
to disable it via profile files..
>
>
> Brian, default USE in IUSE is not a backwards compatable change and this
> is easier ;)
An EAPI bump is pretty simple from where I'm sitting, and implementing
it isn't all that hard.
Meanwhile, the question should be "which is desirable", not "which can
I glue in quickest" ;)
~harring
pgpNhx09lQ91f.pgp
Description: PGP signature
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
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
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@gentoo.org mailing list
Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided
Paul Bredbury wrote: 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. Stop these ad-hominem attacks. Your attitude is more flawed than portage will ever be. -- 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
>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@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] use.force and package.use.force (bug #142853)
Zac Medico wrote:
>Users can unforce them via /etc/portage/profile/{use.force,package.use.force}
>in the usual "-flag" way.
Why new files? Why isn't this just pushed into the use stacking order
over-ridable by the user (default USE flags, and not forcing)?
Then they can over-ride it in package.use just like they do now?
Brian, default USE in IUSE is not a backwards compatable change and this
is easier ;)
/me runs
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided
On Mon, 2006-08-07 at 12:37 +0100, Paul Bredbury wrote:
> > 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).
Fair enough; no* USE flags are an abomination. They're going to be
around for a while yet, though.
How about sci-libs/scipy-0.4.9:
if built_with_use sci-libs/lapack-atlas ifc; then
echo
ewarn "${PN} needs consistency among Fortran compilers."
eerror "lapack-atlas was compiled with IFC, whereas"
eerror "blas-atlas and scipy use the GNU compiler."
eerror "please re-emerge lapack-atlas with 'USE=\"-ifc\"'."
echo
die "Inconsistent Fortran compilers"
fi
> > 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).
No; maths is a tool to make things clearer.
> It's a computer program. Run by people. Who expect it to
> make sense.
Does conflating two conditions to one output make sense?
> These people couldn't care less whether it's "self-dual under
> negation".
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. Not
that it wasn't built at all. Or that Portage has no idea how it was
built.
> 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)
Insufficient information is an error condition.
> when the right answer should be obvious to it (which
> is what my patches do, although this fact has so far been glossed over).
Paranoia much?
>
> The attractive elegance of logical dualism
I think you mean "duality".
> is *not* an excuse for
> programs falling over in a big heap when the correct answer in certain
> circumstances (bug #139693) is obvious.
And in other circumstances?
Ed
Sorry for the spam, all. I'll shut up now.
--
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
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] [PATCH] use.force and package.use.force (bug #142853)
Brian Harring wrote: You're asking on the wrong ml. Profile monkeying really should include a run through of -dev, *especially* something like that that's going to be a pita to turn off when folks start abusing it... Make sure you explicitly state that one *must not* force a flag simply because a build breaks with USE=-foo. Other than that, I'm for it. It will make my job easier :) -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-portage-dev@gentoo.org mailing list
