is this part of package_resolve() necessary?
ThePiGrepper opened this issue · 6 comments
I was wondering what was the purpose/usecase of these lines.
if pkgbase=$(archweb_get_pkgbase "$1") && package_find_remote "$pkgbase" "$2"; then log_info '%s is part of package %s' "$1" "$pkgbase" pkgname=$pkgbase return 0 fi
Obviously this serves a very specific purpose, apparently dealing with package names which somehow have a related 'pkgbase'. what are the usecases for this line, which seems like an special case.
Also, I'm not asking just because, I think I caught a bug in that function.
When this block gets executed without a network connection available, and pkgname does NOT exist, pkgbase will remain empty-valued and pkgname(global) will get overwritten by '', which in turn will return the message:
$ asp checkout
error: unknown package:
Instead of,
$ asp checkout
error: unknown package:
If you're busy I can write a patch, but I'd need to know what is the usecase of that section of code.
This is what makes package lookups work when the pkgname != pkgbase, e.g. try to query for libsystemd or gcc-libs.
Seems to me like the fix is just to change $pkgname to $1 in package_resolve.
1)is this pkgname!= pkgbase situation, the one that happens when one PKGBUILD creates more than one package? or it's something different?
2) I think $pkgname needs to be updated with $pkgbase value to, for instance, checkout the correct branch later on. just changing $pkgname to $1 would stop that from happening, wouldnt it?
- Yes. Split packages.
- I don't really understand this. What branch is meant to be checked out if package resolution fails? I thought the bug was about the empty string that gets printed (though I don't really see how this happens either) when archweb resolution fails?
the issue occurs when:
a) not having a network connection. and
b) trying to find a package which doesnt exist.
because it doesnt exist, it will go through the first package_find_remote() and obviously it will keep going through package_resolve() because pkgname wont be found. then it will enter the block in question, and because there's no connection, this overwriting of "" will occur.
- I think archweb is probably not 'failing' when no connection is detected
Ah, that makes more sense. Going deeper, it appears jq is exiting 0 with empty input. Other people have been bitten by this before:
I guess the simple solution here might be to revert b233ace.
Looking at that patch, indeed it's the simpler solution. I've tested it, and at the very least it solves this issue. can you revert it?