Skip to content

Updating a Package in Optware ng

Anthon Pang edited this page Jan 24, 2018 · 3 revisions

Another way to contribute to the Optware-ng build system is to help in updating packages.

Refer to Contributing to Optware ng to setup a development environment.

Scenarios

Here are some recurring scenarios encountered when building packages:

1. A build fails because the package source has moved

  • Update the base URL for <FOO>_SITE in make/foo.mk
  • If the tarball naming has changed, update <FOO>_SOURCE and <FOO>_UNZIP, if needed
  • Increment <FOO>_IPK_VERSION
  • Future-proof the download to use a mirror (e.g., http://ipkg.nslu2-linux.org/sources) if the upstream isn't available, such as:
$(DL_DIR)/$(FOO_SOURCE):
	$(WGET) -P $(@D) $(FOO_SITE)/$(@F) || \
	$(WGET) -P $(@D) $(SOURCES_NLO_SITE)/$(@F)

2. A newer version of the package source is available

  • Update the upstream version for <FOO>_VERSION in make/foo.mk
  • Save the sha512 hash of the original tarball for upstream package source in checksums/foo-version.ext.sha512 (e.g., checksums/gphoto2-2.5.15.tar.bz2.sha512)
  • Review the patches in sources/foo/ to see if they are still applicable and can be applied cleanly by patch
  • Reset <FOO>_IPK_VERSION to 1

3. Patching a feature or bug

  • Add the patch to sources/foo/
  • Add the patch name to the list of patches in make/foo.mk
  • Increment <FOO>_IPK_VERSION

<FOO>_IPK_VERSION

The package IPK version is reset to 1 on every upstream version upgrade (e.g., from 1.0.0 to 1.0.1). In some cases, the IPK version in related packages must also be reset. For example, if PHP_IPK_VERSION is reset to 1 (in make/php.mk), then PHP_OPCACHE_IPK_VERSION and PHP_APACHE_IPK_VERSION (in make/php-opcache.mk and make/php-apache.mk, respectively) must also be reset.

The package IPK version is incremented by 1 whenever the package content is changed while in the scope of the current upstream version (e.g., still 1.0.0).

Libraries

Care and consideration is required when updating libraries. Generally, when developers follow semantic versioning (MAJOR.MINOR.PATCH, e.g., 1.2.3), we can expect backward compatibility when staying on the same major version (e.g., 1.x.y). And by default, libraries are built as shared or dynamic linked library files.

However, when the above doesn't hold true, you may have to manually track down recursive dependencies and rebuild the numerous packages that link against that library.