Age | Commit message (Collapse) | Author |
|
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
In pkg_hash_fetch_best_installation_candidate, we should not error out if
multiple providers of a given abstract package are present but there is nothing
to differentiate between them (neither is held, preferred, matches the abstract
package name or is already installed). Instead we should just select any valid
provider and get on with the install.
This fixes issue 152.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
The status line for a package for which installation had failed was the cryptic
"install prefer,user not-installed". This is very unclear and doesn't represent
the broken state of the package clearly. Instead we set flags so that we get
"install reinst-required half-installed". This is better but still not perfect
as 'install' could be misinterpreted. Further cleanup of the state formatting
will improve this.
We also give some advice on how to remove package debris or reattempt the
install.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
In the case of upgrading many packages (most likely common case is upgrade
all installed packages), packages may become orphan. Those orphans should
not be upgraded and must be removed.
Use case:
* A1 depends on B1
* A2 does not depend anymore on B
* A1 and B1 are outdated
* A2 and B2 are available.
$ opkg-cl upgrade A
Is fine:
A1 is upgraded to A2
B1 is removed
$ opkg-cl upgrade
Will upgrade A2 and install B2 (remove orphan B1 and install B2).
This patch will halt upgrade of B2 when opkg tries to upgrade a package
marked as "replace".
Signed-off-by: Gaël PORTAY <g.portay@overkiz.com>
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
Upgrade has to copy the flags of the old package.
Signed-off-by: Gaël PORTAY <g.portay@overkiz.com>
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
If we're downloading a non-gzipped "Packages" file it is written straight to
list_file_name and nothing is written to tmp_file_name. So it is list_file_name
that should be verified not tmp_file_name.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
Signed-off-by: Andreas Monzner <andreas.monzner@dream-property.net>
Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
parseDepends sets conflicts->type to DEPEND so we move the setting to CONFLICTS
after the call to parseDepends so that it is not overwritten.
- Fixes 'whatconflicts' sub-command.
Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
Duplicate entries in the depended_upon_by list may cause a package to not be
considered an orphan when it should be, or cause removals to be attempted twice
when removing all dependent packages. Now that depended_upon_by is a pkg_vec, it
is easy to ensure that duplicates do not enter the list.
This change should fix issue 140.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
In pkg_remove_orphan_dependent(), we look for DEPENDS or RECOMMENDS which
existed for old_pkg but don't exist for pkg. Previously this was done by
comparing 'struct depend_t' addresses to see if the exact same dependency
existed in both packages. However, each 'struct depend_t' addressed in the
possibilites list is allocated separately during parseDepends(), so two parses
of the exact same dependency string will result in different pointers. Thus we
should not be directly comparing 'struct depend_t' addresses.
Instead, we can compare the addresses of the abstract packages which each
'struct depend_t' references. These addresses are set via a call to
ensure_abstract_pkg_by_name() which will return the same pointer if it sees the
same pkg name several times as the abstract_pkg_t objects are stored in a hash
table.
This change also ensures that if the constraint within a dependency changes
between old_pkg and pkg, it is not considered an orphan. The constraints of the
dependencies of the new package will already have been checked prior to
installing the new package so we know that such changes will have already been
handled.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
'Recommends'
Signed-off-by: Andreas Monzner <andreas.monzner@dream-property.net>
Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
This change is required to simplify code paths and enable the next couple of
changes.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
If a package is upgraded from an old version to a new version and the old
version RECOMMENDS a package which the new version does not, the recommended
package should be removed if it was auto installed and nothing else requires it.
This fixes issue 144.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
state_flag is set by or-ing together the flags which are set. Therefore, '=='
and '!=' should not be used to check whether a particular flag is set or not.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
We shouldn't require bash just to run this simple script, especially as opkg is
designed for embedded systems.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
--force-removal-of-dependent-packages
While remove pkg with '--force-removal-of-dependent-packages',
pkg may be added to pkgs remove list multiple times, add status
check to make sure pkg only be removed once.
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
constraint_fcn
The use of pkg_name_constraint_fcn is now unnecessary as
pkg_hash_fetch_best_installation_candidate now checks the package name before
setting good_pkg_by_name.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
The behaviour around the variable good_pkg_by_name was changed when the call to
constraint_fcn was moved. The previous behaviour (at v0.2.2) was correct when
pkg_hash_fetch_best_installation_candidate was called from
pkg_hash_fetch_best_installation_candidate_by_name as in that case
constraint_fcn would determine whether the package name matched that originally
requested (hence the variable name "good_pkg_by_name"). However, when
pkg_hash_fetch_best_installation_candidate was called from a different function
this behaviour was incorrect as constraint_fcn was intended to be a hard
constraint.
Assuming that the desired behaviour was to set good_pkg_by_name if the package
name matched the orignally requested name, a new check was introduced around the
code which sets good_pkg_by_name. The originally requested name can be assumed
to be apkg->name.
To give an example of the intended behaviour, say we have packages "x" and
"x_alt" where "x_alt" provides "x", and we're trying to find the best
installation candidate for "x". In this case, good_pkg_by_name would be set to
package "x" as it matches the original name, making it preferable to "x_alt".
This behaviour may still not be perfect, but it restores what I assume to be
the intended behaviour of v0.2.2.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
Now that pkg_hash_fetch_best_installation_candidate treats the constraint
function as a hard constraint, it is not necessary to check that the package
returned by this function actually satisfies the constraint.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
The constraint function used when calling
pkg_hash_fetch_best_installation_candidate should be pkg_constraint_satisfied
not pkg_installed_and_constraint_satisfied.
The constraint function is now treated as a hard constraint on the packages
returned and therefore the previously used constraint function was inappropriate
if we wish to get a list of dependencies to install.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
A couple more debugging messages make things a lot clearer.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
It looks like libtoolize needs the first '-I' argument to ACLOCAL_AMFLAGS in
Makefile.am to match the last call to AC_CONFIG_MACRO_DIR in configure.ac.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
./configure: line 13340: syntax error near unexpected token `$min_gpgme_version,'
./configure: line 13340: ` AM_PATH_GPGME($min_gpgme_version, ok="yes", ok="no")'
This was due to aclocal not knowing about the m4 subdirectory.
Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
There isn't any further work planned before the v0.2.3 release so prepare the
NEWS file with the correct info.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
This file needs to be present so that autoconf doesn't fail on machines without
gpgme installed.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
We need to add an m4 file...
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
Instead of including custom code to find gpgme-config and run it if gpgme was
not found using pkg-config, use the standard AM_PATH_GPGME macro.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
To support linking against gpgme in OpenEmbedded, we need to be able to find
gpgme using pkg-config instead of gpgme-config. Other platforms may still be
using gpgme-config so we need to support both methods. Therefore we check
pkg-config first, followed by gpgme-config.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
After recent changes, packages which fail to satisfy constraint_fcn or the
dependencies of packages already installed will not be added to the
matching_pkgs list. This meant that state_flag was never checked to see if any
of these packages were marked with SF_HOLD and so should not be upgraded.
Therefore, if something had occurred which changes the constraints or
dependencies to be satisfied (for example, installing a different package with
--force-depends whose dependencies are not satisfied by the held package), the
next time the held package is considered it could be upgraded despite the hold
flag being set.
To avoid this issue we add all packages which are marked with SF_HOLD to the
matching_pkgs list without checking constraint_fcn, existing dependencies or
package architecture.
The logic to check members of matching_pkgs for SF_HOLD and SF_PREFER are
preserved later in the function and are still needed. This change simply ensures
they will still work as intended.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
We move the check to see whether a package satisfies the provided constraint_fcn
to an earlier position in the function. It makes more sense to not add a package
to the matching_pkgs list if it fails to satisfy constraint_fcn than it does to
add it to matching_pkgs regardless and then skip over it if it does not satisfy
constraint_fcn.
This has the added advantage of silencing notices that a package would break
existing dependencies or had an incompatible architecture if that package could
not be chosen anyway as it would fail to satisfy constraint_fcn.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
The error message indicating that packages had been found but were incompatible
with the current architecture was printed even if the reason for packages not
being chosen was not due to architecture incompatibility. This could lead to
confusion and so this message was removed.
If the reason for a package not being selected is architecture incompatibility,
a notice is printed to this effect at an earlier stage in the function.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
If we attempt to upgrade a package but the installation of the new version of
the package fails, we need to restore the state_want flags to the values they
would have held prior to the failed installation. This ensures that subsequent
installs or upgrades do not consider the old package as scheduled for removal.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
In the functions opkg_prepare_install_by_name and opkg_prepare_upgrade_pkg, the
package to be installed was not marked with the correct state_want flag. Thus
when resolving dependencies in a combined install or upgrade operation only the
current package was being considered as all other listed packages were not
marked to be installed.
We fix this by setting state_want to SW_INSTALL for each package to be
installed.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
The variables pkg_names_to_install and pkgs_to_upgrade were flagged as maybe
used without initialisation as they were only initialised if conf->combine was
set. However, they are also only used if conf->combine is set so the warnings
were raised in error.
These variables are now initialised to NULL to shut gcc up.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
This command line option is equivalent to the 'combine' config file option.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
When the option is enabled, installs and upgrades will be combined via calls to
opkg_install_multiple_by_name and opkg_upgrade_multiple_pkgs respectively.
This should resolve the case of issue 124 where multiple packages depend on a
common package with version constraints in such a way that all dependent
packages need to be upgraded together.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
This function upgrades multiple packages by name, preparing all packages for
upgrade before any package is upgraded. It should therefore ensure correct
dependency resolution across a group of packages.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
The code to prepare a pkg for upgrade is factored out into the new function
opkg_prepare_upgrade_pkg so that it can be reused.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
This function installs multiple packages by name, preparing all packages for
installation before any package is installed. It should therefore ensure correct
dependency resolution across a group of packages.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
The 'extern "C" {}' wrapping should not surround the inclusion of other header
files as it may cause confusion when compiled as C++.
The unnecessary inclusion of opkg_conf.h in opkg_install.h is also removed and
an inclusion of pkg.h is added to opkg_upgrade.h as necessary.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
The code to prepare a package for installation given a package name is
refactored out into the new function opkg_prepare_install_by_name.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
For some reason apkg->provided_by can include the same abstract_pkg more than
once, causing certain messages to be printed multiple times and possibly
confusing the user. Therefore we try to catch this in
pkg_hash_fetch_best_installation_candidate before iterating through the
providers.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
We do allow such packages to be selected if force_depends is set.
This fixes issue 124.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
The max_count variable is incremented when a package is found with a supported
architecture but its value is never used. After dropping the count and the
associated comment which does not reflect the current behaviour, we can remove
the scope surrounding this loop.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
This function tests whether installing a given package will break the
dependencies of packages which are already installed.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
A colon in a version string should only be interpreted as the epoch separator if
it is the first non-numeric character in the string.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|