summaryrefslogtreecommitdiffstats
path: root/compile
diff options
context:
space:
mode:
authorPaul Barker <paul@paulbarker.me.uk>2014-02-10 07:48:35 (EST)
committer Paul Barker <paul@paulbarker.me.uk>2014-02-23 15:37:19 (EST)
commitafe4b8c3e62594b349bd88bcf4f43b4dcbe0978d (patch)
tree46b45e67f1c96fbe3ccdf0b42561018832901b1b /compile
parent410aebda158f8342d5111df8c2ef9161d611145c (diff)
opkg_prepare_url_for_install: Handle force_reinstall as upgrade
The best way to handle force_reinstall is to make the reinstall look like an upgrade - because we already have a good package upgrade path. With the new per package force_reinstall flag this is now possible. In opkg_prepare_url_for_install, we set the per-package force_reinstall flag for the given package. As this function is only called for packages explicitly specified as arguments to 'opkg install' or 'opkg_install_package', the flag will only be applied to the indended packages. If a package name is given which exists in a package feed then we need to cheat a little. We lookup the package in the feed and get its local filename and then act as if that path were given as a URL. This function is the best place to handle the force_reinstall flag as it is responsible for setting the package hash table up so that pkg_hash_fetch_best_installation_candidate_by_name() returns the intended pacakge. The old logic in opkg_install_cmd which calls opkg_remove_cmd to remove the previously installed package is no longer needed and is removed. This solves issue #71 without causing a regression on issue #51. Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
Diffstat (limited to 'compile')
0 files changed, 0 insertions, 0 deletions