diff options
author | Paul 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) |
commit | afe4b8c3e62594b349bd88bcf4f43b4dcbe0978d (patch) | |
tree | 46b45e67f1c96fbe3ccdf0b42561018832901b1b /tests/regress/Makefile | |
parent | 410aebda158f8342d5111df8c2ef9161d611145c (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 'tests/regress/Makefile')
0 files changed, 0 insertions, 0 deletions