Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 40993 - use/has are noisy (document hasq/useq)
Summary: use/has are noisy (document hasq/useq)
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Documentation (show other bugs)
Hardware: All All
: High major (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords: InVCS
Depends on: 56408
Blocks:
  Show dependency tree
 
Reported: 2004-02-09 11:44 UTC by Aron Griffis (RETIRED)
Modified: 2005-07-14 06:58 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aron Griffis (RETIRED) gentoo-dev 2004-02-09 11:44:45 UTC
As of 2.0.50, repoman spews USE flags to the screen.  There should be a bugzilla severity of "incredibly annoying".  Please apply this patch ASAP.  We've been through this before.  The current behavior is a regression.

--- ebuild.sh.shutup    2004-02-09 14:37:09.000000000 -0500
+++ ebuild.sh   2004-02-09 14:37:17.000000000 -0500
@@ -89,7 +89,7 @@
 
 use() {
        if useq ${1}; then
-               echo "${1}"
+               [ -t 1 ] || echo "${1}"
                return 0
        fi
        return 1
Comment 1 Nicholas Jones (RETIRED) gentoo-dev 2004-02-09 23:33:21 UTC
What happens if you echo to a closed terminal?
Does it die on a broken pipe?

I changed this hide-the-output functionality to
simplify things. There are too many random conditions
related to serial terminals, subshells, and emulated
terminals to continue trying to deal with it. I'd
rather have people fix everything and stop using
[ `use blah` ] syntax.
Comment 2 Aron Griffis (RETIRED) gentoo-dev 2004-02-10 14:12:00 UTC
Nick, I'm sorry but I'm having trouble making sense of your comment.

>I changed this hide-the-output functionality to
>simplify things. There are too many random conditions
>related to serial terminals, subshells, and emulated
>terminals to continue trying to deal with it.

What random conditions do you mean?  Sure, any of the above might exist.  The point of this patch is to make ebuild.sh quiet when the output is a terminal identifiable by isatty().  I simply cannot imagine a case when this patch would break anything, it just makes repoman and emerge generate less noise.

>I'd rather have people fix everything and stop using [ `use blah` ] syntax.

I think that would be great!  But removing the terminal check for stdout doesn't  encourage people to change.  If you want people to change, talk to the people maintaining the ebuild documentation and get some stuff written up about the cleaner syntax, i.e. "if use blah; then"
Comment 3 SpanKY gentoo-dev 2004-02-10 16:39:50 UTC
perhaps a better way to start enforcing this is through repoman ... after all, we could ask developers to change but they might keep doing it unconsciously (i know i would probably slip)

personally i thought that the issue was [ -z "`use blah`" ] ... i thought that [ `use blah` ] worked only because 0 was returned and not because a string was echoed
Comment 4 Aron Griffis (RETIRED) gentoo-dev 2004-02-11 10:51:49 UTC
[ `use blah` ] works because a string is echoed, it's just ugly syntax.

But I think we're straying from the point of this bug.  The point is that emerge and repoman are annoyingly noisy because the terminal check was unnecessarily removed from /usr/sbin/ebuild.sh.  Would the portage devs mind applying my patch (please) then we'll take the ebuild-grammar discussion to gentoo-dev@g.o?
Comment 5 Marius Mauch (RETIRED) gentoo-dev 2004-02-11 11:15:43 UTC
As Nick already said, there are too many side-conditions for the terminal check to work reliable that result in error messages that are worrying for uninformed users.
Comment 6 Aron Griffis (RETIRED) gentoo-dev 2004-02-11 11:49:13 UTC
As discussed on IRC with genone:

19:42 <@genone> agriffis: let me find the bug about userpriv and /dev/stdin errors 
                ...
19:43 <@agriffis> genone: ok, but the terminal check never touches /dev/stdin.  
                  I've tested "[ -t 1 ]" with a variety of circumstances (pipe, 
                  xterm, screen, closed fd) and there are simply no issues.
19:44 <@genone> agriffis: you using userpriv ?
19:44 <@agriffis> genone: yes
19:44 <@agriffis> genone: and I have been running with the patch in that bug for a 
                  long time.
19:44 <@genone> agriffis: well, it was a problem with the old check
19:45 <@agriffis> genone: that is possible.  I think the old check used the tty 
                  prog instead of the bash built-in [ -t ]
19:46 <@genone> agriffis: can you add your expierences to the bug, I guess others 
                are like me and think they are equivalent
Comment 7 Aron Griffis (RETIRED) gentoo-dev 2004-02-16 14:51:12 UTC
ping... Nick?  Marius?
Comment 8 Aron Griffis (RETIRED) gentoo-dev 2004-03-29 11:44:01 UTC
Would the portage team please apply this patch?  It is tested, works, etc.
Comment 9 Mr. Bones. (RETIRED) gentoo-dev 2004-04-07 14:16:45 UTC
Why has there been no recent comments from the portage team on this bug?
Please apply this patch.
Comment 10 Masatomo Nakano (RETIRED) gentoo-dev 2004-04-09 14:24:07 UTC
carpaski, genone:

I don't know this problem well.
Can you fix or explain this?
Comment 11 Nicholas Jones (RETIRED) gentoo-dev 2004-04-12 19:41:31 UTC
No comments from me because my query decided to randomize date orders
and I haven't see this for a long time.

This doesn't fix the problem still.

Eventually there will be no terminal involved with ebuild.sh...
It'll be an FD cloned operation -- 'pipe to a file' or 'pipe
to a process'. The output will get printed to that process/file.
By leaving it as is, it's incentive to fix it in the ebuilds.

useq is a quiet version.
hasq is also a quiet version.

Comment 12 Aron Griffis (RETIRED) gentoo-dev 2004-04-13 09:00:50 UTC
carpaski, the term "eventually" here doesn't give me any warm fuzzies, but thanks for taking a look at this bug.

regarding a couple things you said, would you mind pointing to some documentation for me?  I'd like to see where useq/hasq are documented, and also I'd like to know more about your plans for ebuild.sh.  Thanks.
Comment 13 Nicholas Jones (RETIRED) gentoo-dev 2004-04-13 17:55:38 UTC
vapier: wanna document it?

agriffis: The operations will be passed off to other processes if they
so desire to take it. GUI frontends will probably want to take control
of output if they are controling the operation. It's nicer than forcing
a forks and execs. You cannot guarentee that an operation is actually on
a terminal. SSH can influence it, pty's can be used for various reasons,
and it's _really_ aggitating to fix things after fixing them for broken
fixes.
Comment 14 SpanKY gentoo-dev 2004-04-13 18:52:40 UTC
i'm already on the portage list :p

lets review ...
`use` is noisy thus people dont like it
`useq` is not noisy thus it should be documented and we should educate people to start using it ?

i dont really like that path ... i think it should be the other way around ...
use -> quiet
usev -> echo the use flag

the large majority of the time people dont want the use flag echoed back, but sometimes they do (i know i've done code like this:
for d in `use X` `use svga` `use SDL` ; do)

many times people have [ ! -z "`use blah`" ] or [ `use blah` ] or [ -z "`use blah`" ] ... we can *easily* substitute with use blah or ! use blah ... i know i've been changing ebuilds in the tree as i come across them ...

in other words we educate people on wtf '[ "`use blah`" ]' means and why it works in the same exact mannor as 'use blah'
Comment 15 Mr. Bones. (RETIRED) gentoo-dev 2004-04-30 02:07:34 UTC
I totally agree with Spanky on this.  I'd really like to see use quieted and
usev added in place of the use/useq idea.
Comment 16 Aron Griffis (RETIRED) gentoo-dev 2004-05-02 14:14:55 UTC
carpaski, what do you think of spanky's and mr_bones_'s suggestion?  I like the idea.  If we go this route, then I suppose here are the necessary steps:

1. get usev into portage
2. fix the ebuilds that call use from $() or `` by either (a) changing the ebuild to use different logic or (b) changing the ebuild to call usev
3. make use quiet

I am willing to do the work for #2 if you're willing to do #1 and #3 :-)
Comment 17 Aron Griffis (RETIRED) gentoo-dev 2004-05-24 20:41:43 UTC
Carpaski, any word on what I said in comment 16?
Comment 18 Aron Griffis (RETIRED) gentoo-dev 2004-07-19 17:02:46 UTC
Current status on this bug:

All ebuilds in portage are converted to the newer use invocation.  I.e. none of them are using the deprecated [ `use foo` ] syntax, so it should be almost safe to make use() silent at this point.

The only exception is for ebuilds that are presently installed on user systems which expect use to make some noise.  I think that ferringb has something to add for that, but if not, we'll figure something out...
Comment 19 Brian Harring (RETIRED) gentoo-dev 2004-09-02 19:24:21 UTC
The use/has silencing shouldn't be changed in portage until the environment is properly reloaded- if use/has's behaviour changes prior to portage correctly reloading the older function from the saved env, the ebuild's use/has no longer work as expected.
This is blocked by bug #56408, which is pretty much ready to go.
Comment 20 Nicholas Jones (RETIRED) gentoo-dev 2004-10-22 08:47:48 UTC
Bug has been fixed and released in stable portages on or before 2.0.51-r2
Comment 21 Brian Harring (RETIRED) gentoo-dev 2004-10-27 02:20:11 UTC
This never went out in -r2.
Comment 22 Brian Harring (RETIRED) gentoo-dev 2004-10-27 03:19:23 UTC
Added, the issues I pointed out in #56408 still exist.
This _will_ cause complications for unmerging pkgs if the (pre|post)rm does any form of use checking and expects the older behaviour (likely if the pkg was installed 2/3 months back).
Comment 23 Jason Stubbs (RETIRED) gentoo-dev 2005-07-14 05:47:40 UTC
Fixed on or before 2.0.51.22-r1 
Comment 24 Jason Stubbs (RETIRED) gentoo-dev 2005-07-14 06:58:28 UTC
Looking through the batch of bugs, I'm not sure that some of these are 
actually fixed in stable. Others, the requirements have possibly changed after 
the initial fix was committed. 
 
If you think this bug has been closed incorrectly, please reopen or ask that 
it be reopened.