Always include target package in buildorder? #32
Comments
|
Yes,. I've been rethinking what this output should contain. Roughly, I want to discard the idea that anything is omitted, but rather indicate in the output that the dep is already satisfied. |
|
Yeah, that sounds great. I was actually surprised the local database was queried at all for this command. |
falconindy
added a commit
that referenced
this issue
Apr 27, 2019
This should help to address a few user requests: 1) buildorder shouldn't consider what's installed and omit these packages. Instead, we tag output to describe what steps (if any) need to be taken. Output is either REPOS (available for install via pacman), or AUR (can be built from the AUR). Either of these can be prefixed with SAITSFIED to denote that the dependency is already installed locally. As a last resort, a depedency might be UNKNOWN when the package isn't found anywhere (#4). 2) buildorder should include the target package(s) in the output. (#32) 3) For packages which come from the AUR, the pkgbase will be emitted as a third column, e.g. AUR systemd-libs-git systemd-git This allows for deduping and also knowing the directory the cloned/downloaded package will be found in (#9) I'll no doubt gain a few new bug reports with this change...
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
buildorderlists all AUR dependencies that aren't already installed on the system. This is also true for the target package specified on the commandline. Soauracle buildorder foowill only include foo if it's not already installed. But since the point ofbuildorderis to gauge what needs to be done to build the target package, it might make sense to always include it in the buildorder list?The text was updated successfully, but these errors were encountered: