| Age | Commit message (Collapse) | Author |
|---|
|
If this option is set, the maintainer's changes to a conffile will be ignored
and a message will be printed to indicate that this has happened. This option is
useful when it is known that the user's changes to a conffile should override
those made in an upgrade of a package and allows space to be saved within the
configuration directory.
This completes the fix for issue 128.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
If a conffile has been changed and force_maintainer is not set, a message should
be printed at the level of NOTICE not at the level of ERROR. The user still
needs to know that there may be changes to the conffile which need to be merged,
but this is not an ERROR as it does not indicate that something wrong has
happened.
This partially fixes issue 128.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
By default, gpg signatures will be used.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
The default behaviour of opkg is changed to allow local files to be linked
rather than copied into the cache directory. However, if the cache_local_files
option is set, the old behaviour will be followed and local files will be copied
into the cache.
A local file is any which is accessed using a 'file://' protocol.
This patch fixes issue 139.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
If the check_pkg_signature option is set, a signature file will be downloaded
for each package file and this signature will be validated before the package is
installed. This adds an additional layer of security to the use of opkg.
This patch fixes issue 132.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
The opkg_download_pkg function previously handled both downloads to the cache
and downloads to a specified directory. This function now handles only downloads
to the cache, downloads to a specific directory are now handled by
opkg_download_pkg_to_dir. The common code to initialise the url variable is
split out into get_pkg_url.
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>
|
|
With packages A (Version: 2.0) and B (Conflicts: A (<< 1.0)) installed,
it wasn't possible to upgrade A to a newer version since commit 2e2329b.
Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
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>
|
|
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>
|
|
To ensure that the lock file can be created, we need to first create the parent
directory if it does not already exist.
This fixes issue 110.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
The code to create the lock file is factored out of opkg_conf_load into
opkg_lock and the code to destroy the lock file is factored out of
opkg_conf_deinit and the error handling code of opkg_conf_load into opkg_unlock.
This ensures that the unlocking code is consistent between the two places it is
needed and improves readability.
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>
|
|
Replace providers of virtual packages that are conflict/provide/replace by another package
This fixes issue 89.
Signed-off-by: Carl Cospel <ccospel@gmail.com>
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
This fixes issue 125.
Signed-off-by: Carl Cospel <ccospel@gmail.com>
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
If lists_dir is set using the old syntax after it has already been set, we need
to free the memory associated with the previous setting.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
The current syntax for lists_dir in v0.2.2 and earlier is
lists_dir ext <path>
where 'ext' is ignored.
The syntax for lists_dir in v0.3.0 and onwards will be
option lists_dir <path>
For the v0.2.3 release, we wish to support both syntaxes so that users can
prepare their config file for the upgrade to v0.3.0.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
config.h defines things like _FILE_OFFSET_BITS and so must be included in every
C file before any other headers are included.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
This ensures that packages which are recommended by another installed package
are not removed when opkg_config->autoremove is set. As this is currently the
only use of the depended_upon_by array, it should be a safe change to make. If
depended_upon_by is put to other uses in the future, the dependency type of each
entry may need to be checked.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
Recent changes added entries in the options array for members of the opkg_config
structure which didn't previously have an associated option. This caused the
memory pointed to by opkg_config->lock_file and opkg_config->lists_dir to be
freed when the options array was de-initialised. In two cases one of these
variables had already been freed but not set to NULL, causing a double free
error at runtime.
In addition, the opkg_config->lock_file variable is needed in order to unlink
the lock file during opkg_conf_deinit. Therefore, this call to unlink must occur
before the options array is de-initialised.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
Only one definition remained in opkg_defines.h after recent changes, it is
simpler just to include it in opkg_conf.h.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
The default paths listed in opkg_conf.h are now given in full rather than
relative to OPKG_STATE_DIR_PREFIX.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
The default cache directory should be under /var/cache, not /var/lib.
This fixes issue 131.
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>
|
|
We need to ensure that the directory which will contain the status file exists
so that we don't get an error when creating/opening the status file.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
|
This option is used to set the status_file_name for each pkg_dest and will be
interpreted as relative to the root_dir of the pkg_dest. It eliminates the need
for the OPKG_STATUS_FILE_SUFFIX symbol and allows more control over where the
status file directory is placed.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
|
Paul Barker
Andreas Oberritter
Carl Cospel