Mon 04 Apr 2016 01:57:47 PM UTC, comment #5:
Recording some thoughts here for a workable hack vs a better fix:
most of pkg.m is a top level wrapper with work in the private functions. In particular, pkg update calls install.m for each package after generating a list to iterate through. install.m has 'unsatisfied dependency' as an error, so this aborts the whole update process. install.m is called without any expected return variables, so there's no feedback to pkg.m, and dependencies aren't checked by pkg.m, just inside install.m
1 - bare minimum fix: "don't abort the pkg.m update sequence when a dependency error is encountered."
--> is there a way for the error (or something similar) to only abort the current script and return control to the calling function pkg? Would there be a problem if this was replaced with a warning? for a single pkg install, I believe either a warning or an error would be the last thing done by the script. for multiple installs, a warning would inform the user but still continue to try the other packages.
2 - #1 + inform the user in some way that they should re-run pkg update - if changed to a warning, there should be a way to check if a particular warning was issued, change a flag to 'dependency_error_encountered', and then at the end of the update process, produce a 'you should re-run pkg update' message.
3 - if #2 is happening, other things could be triggered by the flag, such as logging the package(s) that caused the error, and retrying them once at the end of the update script.
4 - the most desirable option, that pkg checks for dependencies and re-orders the update list so that nothing occurs out of order, would require moving (copying) the dependency check from install to pkg. Not too difficult, but much more involved.
|