A cower "warning" is blocking the download command, and can't be overridden #77

Closed
epitron opened this Issue Jan 23, 2014 · 16 comments

Projects

None yet

4 participants

@epitron
epitron commented Jan 23, 2014
$ cower -d tup-git
warning: tup-git is available in archlinuxfr

$ cower -df tup-git
warning: tup-git is available in archlinuxfr

$ ls tup*
ls: cannot access tup*: No such file or directory

NOTE: The tup-git package isn't installed, it's just in one of my arch repos.

@alferpal

Cower won't download if the said package is in a repo. In your case, that's archlinuxfr. And I believe that's how it's intended to work.

@epitron
epitron commented Jan 23, 2014

These things are all true, but that's not the definition of a warning. Warnings are advice, and allow the program to continue, while errors are for unresolvable problems. Something is wrong here.

If it's intended to be an error, it should at least be overridable with -f.

@falconindy
Owner

Cower would continue, but you haven't given it any other packages. If you want to get around the warning, then you need to tell cower to ignore the repo so that it looks in the AUR. See the --ignorerepo flag and the similar config option.

The force flag already has another meaning -- clobbering existing directories (as per the main page). I don't see a reason here to overload its meaning.

And on a semi-related note, the archlinuxfr repo historically has been full of broken and wrongly built packages. I think you'd be a lot happier if you just disabled it.

@epitron
epitron commented Jan 23, 2014

Ah, thanks for the tip.

So, I think it would be nice if the message was fixed. First, to mention "--ignorerepo", and second to say "error" instead of "warning". Those two things would make it a lot easier for whoever else encounters this situation.

Personally, I think it would be nice to have all the override features combined as "-f". (Maybe that's not technically possible, since there are orthogonal overrides.)

@falconindy
Owner

I don't really see it as an error, though. The package is available, but cower isn't going to get it for you because it's outside its jurisdiction.

A reminder every time we encounter a package in a binary repo seems harsh, and it's really only relevant for repos other than the official arch repos. I've no interest in filtering that.

Perhaps the thing to do is to change up the resolve order and always try to get the package from the AUR first. I'll have to think about this.

@falconindy
Owner

Not going to implement this, sorry. The ordering is fine as is, and the --ignore facilities will let you accomplish what you want.

@falconindy falconindy closed this Sep 6, 2014
@epitron
epitron commented Sep 6, 2014

What about adding some helpful information to the error message, saying that it didn't download the pkgbuild files, and to use "--ignorerepo" to override it?

@epitron
epitron commented Sep 13, 2014

Look, the core problem I'm having is that the command is failing to do what you asked, and there's no indication of that - just a warning. The user has to inspect the directory, and then Google around to figure out how to fix it. Don't you think that's sort of inconsiderate?

@falconindy
Owner

No indication? The command fails as expected:

    $ cower -d gcc; echo $?
    :: gcc is available in testing
    1

Anyways, 153b8f8 does what you want.

     ┌┤master ~/code/cower
     └➤ ./cower -d gcc
    :: gcc is available in testing (ignore this with --ignorerepo=testing)
     ┌┤master ~/code/cower
     └➤ ./cower -d gcc --ignorerepo=testing
    :: gcc is available in core (ignore this with --ignorerepo=core)
     ┌┤master ~/code/cower
     └➤ ./cower -d gcc --ignorerepo=testing,core
    :: gcc is available in multilib-testing (ignore this with --ignorerepo=multilib-testing)
     ┌┤master ~/code/cower
     └➤ ./cower -d gcc --ignorerepo=testing,core,multilib-testing
    :: gcc is available in multilib (ignore this with --ignorerepo=multilib)
     ┌┤master ~/code/cower
     └➤ ./cower -d gcc --ignorerepo=testing,core,multilib-testing,multilib
    :: no results found for gcc
@epitron
epitron commented Sep 13, 2014

Thanks... it would still be nice if it said "Error: gcc is available in testing", but whatever. :)

@rmarquis
Contributor

The last commit (66c28d6) also feels weird to me. I understand the repo package isn't downloaded, but I wouldn't say that an error occurring because a package/PKGBUILD doesn't exist at all is the very same as an "error" that occurs because a repo package doesn't have a PKGBUILD in the AUR, where I feel a warning is much more adequate.

On a side note, the last change is also annoying for wrappers as it was super easy to make the difference between AUR and repository packages (pacaur/meat/..).

@falconindy
Owner

where I feel a warning is much more adequate.

Which has pretty much been my stance all along...

Clearly, I can't win.

@rmarquis
Contributor

Clearly, I can't win.

Well, what prevents you to revert to a more adequate and seemingly more useful warning?

@falconindy
Owner

Isn't this report sufficient to show that not everyone agrees that it should be a warning? I'm not sure why changing a warning to an error breaks things for you.

@rmarquis
Contributor

Isn't this report sufficient to show that not everyone agrees that it should be a warning?

I was actually wondering why you changed it to an error while you, as the creator, believe that it should be a warning.

Cower wrappers usually use the warning/error flags to check if the package is available in the repositories or not. There're only a few side effects in the current version of pacaur, but meat seems broken (to make it short, pacaur's current code doesn't use cower dependency solver, but I want to get back to it once AUR 4.0.0 shows up).

@falconindy
Owner

I was actually wondering why you changed it to an error while you, as the creator, believe that it should be a warning.

Because after I hear the same complaint enough times, I start to wonder if my opinion is the minority. Whatever, I'm reverting it since it breaks historical behaviors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment