inconsistent output when using --brief option #26

Closed
rmarquis opened this Issue Aug 27, 2011 · 4 comments

Projects

None yet

2 participants

@rmarquis

When using --brief option, the normal and expected result is similar to the below output:

$ cower -dd -f -b clyde-git
 S      clyde-git       :: clyde-git downloaded to /home/directory
 W      lua-lzlib       :: lua-lzlib is available in community
 S      lua-yajl-git    :: lua-yajl-git downloaded to /home/directory
 W      luasocket       :: luasocket is available in community
 W      luafilesystem   :: luafilesystem is available in community
 W      luasec  :: luasec is available in community

However, in some cases the command output additional lines that shouldn't be displayed. See the following (two last lines)

cower -dd -f --color=always -b arson
 S      arson   :: arson downloaded to /home/directory
 S      ruby-json       :: ruby-json downloaded to /home/directory
 W      ruby    :: ruby is available in extra
 W      rubygems        :: rubygems is available in extra
 S      ruby-facets     :: ruby-facets downloaded to /home/directory
 S      ruby
 S      rubygems

Another random example is obtained with the package "gnome-shell-extension-zodiac-autohidetopbar-git"

cower -dd -f --color=always -b gnome-shell-extension-zodiac-autohidetopbar-git
 S      gnome-shell-extension-zodiac-autohidetopbar-git :: gnome-shell-extension-zodiac-autohidetopbar-git downloaded to /home/directory
 S      gnome-shell-extensions-zodiac-common-git        :: gnome-shell-extensions-zodiac-common-git downloaded to /home/directory
 W      gnome-shell     :: gnome-shell is available in extra
 W      intltool        :: intltool is available in extra
 W      gnome-doc-utils :: gnome-doc-utils is available in extra
 W      gnome-common    :: gnome-common is available in extra
 S      intltool
 S      gnome-doc-utils
 S      gnome-common

After having had a look at the respective pkgbuild, it seems cower does not parse the depends / makedepends arrays correctly when the packages aren't in singe quote, ie:
depends=(ruby-json ruby-facets) instead of depends=('ruby-json' 'ruby-facets')

I am not sure if this is a cower bug or not, as the pkgbuild seems not to follow common practice. However, this seems fairly common on the aur (after arson, I tested a random pkgbuild and found the same issue).

@falconindy
Owner

No, this all makes sense. In the second case, ruby and rubygems were already mentioned, but they were encountered again by a dependency of arson. No message is provided because you already know about it. Simple rule -- if there's no third field, skip it.

cower seems to have no problems parsing dependencies here, as "cower -ii --format %D arson" correctly shows ruby-json and ruby-facets:

$ cower -ii --format '%D' arson
ruby-json  ruby-facets
@rmarquis

Yes, I know that cower -ii correctly report dependencies, and thought that this issue was specific to --brief mode only so I reported it.

I do not know what "S" stand for, but I thought it means "Success" (BRIEF_OK) and that it was reported for aur dependencies only (download ok). I'd say it is a bit strange to report both "W" and "S" status for the same package and I have to confess that I still don't get the reason - maybe a technical issue?. It would also be easier to treat "W" as a binary deps result and "S" is an aur dep result, but there is an easy workaround as you mentioned it.

Oh, and thanks for your quick answer, as always.

@falconindy
Owner

It's probably more accurate to say S means "satisfied", either by way of "cower just downloaded it" or "it's already taken care of". Messaging is the only thing that -b changes. None of the backend logic is duplicated.

@rmarquis

Yes, "satisfied" makes much more sense to me. Thanks for explaining!

@rmarquis rmarquis closed this Aug 27, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment