Checkpkg Error Tags

Overview

This page contains additional information for checkpkg error tags. If you see something that can be corrected and/or enhanced on this page, please make the appropriate changes.

All error tags found in packages in the catalog can be accessed here.

Error tags

action-class-only-in-pkginfo

There is an action class that exist in pkginfo, e.g.

CLASS = someclass none

but there's no file in pkgmap using that class. While it isn't an error in itself, it indicates that perhaps a file in pkgmap is missing class assignment.

Recommended fix: Investigate why the class is not referenced from the prototype. One cause may be that the Prototype Modifier setting the class does not match. If the lack of usage is intentional the class should be removed from pkginfo.
When to override: There is no known case where this may be necessary.

action-class-only-in-pkgmap

A file in pkgmap uses an action class which is not declared in pkginfo. While this can be useful if classes to be installed are determined in a request script this not used for OpenCSW packages.

Recommended fix: Declare the class in pkginfo. In GAR this should happen automatically and is considered an error when this checkpkg error is thrown.
When to override: There is no known case where this may be necessary.

archall-devel-package

Although devel package often don't contain binaries they still may contain architecture-specific information like pathes to 64 bit files. It's safer to always make them architecture-specific. Space savings are small, and problems caused by development packages from another architecture are often hard to debug.

Recommended fix: Do not make the development package ARCHALL as described in Dynamic Package Files
When to override: The only allowed usecase is when the development package is an empty transitional package. When using GAR Obsoletions this error is automatically overridden.

archall-with-arch-paths

There are architecture-specific paths (e.g. sparcv9 or amd64) in the package, which indicates that it should be architecture-specific.

Recommended fix:
When to override:

archall-with-binaries

The package is marked as being architecture-neutral ("ARCH=all"), but seems to contain binaries.

Recommended fix: Either put the binaries in another package or do not mark the package as ARCHALL.
When to override: The detection of the filetype may be wrong as it is driven by a heuristic. However, instead of just overriding the error it would be better to report and fix the issue in libmagic.

bad-location-of-file

Files provided by OpenCSW packages should be under following directories:

  • /opt/csw
  • /etc/opt/csw
  • /var/opt/csw

Files placed elsewhere are probably a bug.

Recommended fix: Put the files in the above listed directories.
When to override: One exception are the class action script packages, which delivered files to /usr/sadm/install/scripts. Other locations (like /etc/services should better be done by the use of an existing class action script. Before overriding please consult maintainers@ first.

bad-rpath-entry

A binary contains an rpath/runpath entry which looks to be an invalid one.

Recommended fix: If the paths in question are related to the Solaris Studio compiler, try adding for C

EXTRA_LINKER_FLAGS = -xnorunpath

or for C++ 
EXTRA_LINKER_FLAGS = -norunpath

and making sure the flag is propagated to the linker. This may require patching libtool as the above flags are not recognized to be passed to the linker by default in libtool. The OpenCSW libtool is patched to pass the flags, but application would require a libtoolize bootstrapping which is too heavy most of the main as opposed to patching ltmain.sh.
Examples:

When to override: Sometimes pathes are inherited from legacy packages which only contain a trailing slash like /opt/csw/lib/ which is pretty much the same as the valid /opt/csw/lib.

base-directory-missing

The file in question defines an action script class, which doesn't necessarily support implicit directory creation, but needs that directory to exist, and that directory is not provided by the package or its dependencies.

Recommended fix:
When to override:

binary-architecture-does-not-match-placement

On the sparc architecture, binaries in /opt/csw/bin need to be at most a sparcv8 binary on Solaris 9 and at most a sparcv8+ binary on Solaris 10. A sparcv9 binary must be placed under a subdirectory, e.g. /opt/csw/bin/sparcv9.

A typical failure mode happens when CFLAGS from GAR are ignored by the build system, which causes Solaris Studio to produce sparcv8+ binaries, instead of sparcv8.

Recommended fix: Make sure that CFLAGS are propagated properly.
When to override: Do not override. When in doubt, ask on the maintainers mailing list.

binary-disallowed-placement

An example would be an sparcv8 binary in the /opt/csw/bin/sparcv9 directory.

Recommended fix: Analyze how CFLAGS are propagated through the build system.
When to override: Do not override. When in doubt, ask on the maintainers mailing list.

binary-wrong-architecture

An example is a sparc binary in a i386 package.

Recommended fix: Build the package again.
When to override: Do not override.

catalogname-does-not-match-pkgname

The standard package name is CSWfoo-bar with a catalog name foo_bar (no CSW-prefix and '-' replaced by '_').

Recommended fix: Adjust the catalog name according to the package name. For GAR this setting is described in Dynamic Package Files
When to override: For legacy packages the package and catalog names often don't match. If you want to keep them as they are just override the reported error. Please do not override the error for new packages!

catalogname-does-not-start-with-py_

Recommended fix:
When to override:

dependency-listed-more-than-once

As the name says, it means that a dependency is listed more than once.

Recommended fix: Take out the reported dependency once. The dependent package may be added by GAR automatically, so it may be reported even if you have it defined yourself only once.
When to override: Adding a dependency multiple times does not gain anything and it always is an error.

depends-on-self

The reported package has a dependency to itself.

Recommended fix: Take out the reported dependency.
When to override: As this dependency can never be resolved cleanly this is always an error and should never be overridden.

deprecated-library

This means a legacy library has been linked in. This is either a library with a degenerated original name where a newer one exists but needs special treatment (like libnet.so) or a wrong (=legacy) location when the library is present at more than one location. For example, libdb-4.7.so is found in CSWbdb and CSWbdb47, and it's important to throw an error if the RPATH is /opt/csw/lib:/opt/csw/bdb47/lib, and not to throw an error if RPATH is /opt/csw/bdb47/lib:/opt/csw/lib

Recommended fix:

  • For libnet, which just needs linkage to a different libnet.so and no special RPATH please use as described in project libnet:
EXTRA_LDFLAGS = -L$(libdir)/libnet-new
  • For other libraries needing updated RPATH please use something like this:
EXTRA_LIB += /opt/csw/bdb47/lib

When to override: Please do not override this error.

disallowed-path

Recommended fix:
When to override:

discouraged-path-in-pkgmap

Some files are not allowed by default in a package for various reasons. The following files are to be avoided:

  1. *.pyc and *.pyo: Python files are usually compiled by using the CAS cswpycompile.
  2. */lib/*.a: Static libraries are usually not shipped.
  3. */lib/*.la: These libtool linkage files are harmful to compilation as they may contain compile time pathes which break libtool linkage.
  4. /opt/csw/var/.*: As this may be inherited in a sparse root environment the location /var/opt/csw is preferred.
  5. .git: A directory of this name indicates a GIT repository which is mostly present in development environments.
  6. .CVS: A directory of this name indicates a CVS repository which is mostly present in development environments.

Recommended fix:

  1. *.pyc and *.pyo: Use PYCOMPILE = 1 in the GAR Makefile to trigger the use of CAS cswpycompile.
  2. */lib/*.a: Static libraries are usually excluded by default in GAR. If you want to include them set MERGE_EXCLUDE_STATICLIBS =
  3. */lib/*.la: Libtool linkage files are usually excluded by default in GAR. If you want to include them set MERGE_EXCLUDE_LIBTOOL =
  4. /opt/csw/var/.*: Relocate the files to /var/opt/csw. This can be changed by setting sysconfdir.
  5. .git: Exclude the directory e.g. with EXTRA_MERGE_EXCLUDE_FILES = .*/\.git
  6. .CVS: Exclude the directory e.g. with EXTRA_MERGE_EXCLUDE_FILES = .*/\.CVS

When to override:

  1. *.pyc and *.pyo: There is no known usecase for an override.
  2. */lib/*.a: Some packages need static libraries, e.g. DynaLoader.a from Perl which is needs to be statically linked to binaries using the Perl interpreter.
  3. */lib/*.la: There is no known usecase for an override.
  4. /opt/csw/var/.*: Please note that overriding this error will break sparse root compatibility.
  5. .git: The directory may be part of the package and be named like this by coincidence.
  6. .CVS: The directory may be part of the package and be named like this by coincidence.

file-collision

A file in the package is also present in another package yielding in a collision which would be reported by pkgadd during installation of the two packages.

Recommended fix: This error can happen in different usecases:

  1. When an existing package is split and the old package is rebuilt from another recipe: A collision would be reported, although the other package with the colliding files would be also rebuild to no longer contain the problematic files. It may be best to use FOREIGN_PACKAGES as explained in the GAR Wiki: Obsoleting Packages.

When to override: This error should not be overridden. If there exist other packages from other recipes submitted in the batch this error should be ignored, but not overridden so checkpkg has a chance of detecting more problematic pathes probably present in the whole batch.

file-with-bad-content

This means occurrences of specific strings like /usr/local or /usr/share have been detected which probably should better be /opt/csw and /opt/csw/share.

Recommended fix: The occurrences may be replaced after the install phase with something like this:

REINPLACE_USRLOCAL += $(mandir)/man1/rsync.1
REINPLACE_USRSHARE += $(mandir)/man1/rsync.1

or more generally 
REINPLACE_MATCH = /etc/clpbarrc
REINPLACE_WITH = /etc/opt/csw/clpbarrc
REINPLACE_FILES += args.c

For details see the GAR Wiki: Reinplace.

When to override: When the strings are used in unrelated examples or search pathes the occurrence is perfectly ok and overriding is necessary.

gzipped-manpage-in-pkgmap

This occurs when the pkgmap of your package has files matching /opt/csw/share/man/*/*gz. Other platforms have a man that will gunzip manpages before displaying them, but Solaris' man can't do this. If a package assumes a platform with this capability and delivers compressed manpages, those are not useful to the end user.

Recommended fix: Use gunzip to deliver uncompressed manpages.
When to overrided: There is no known case where you should override this.

init-file-missing-cswinitsmf-class

Recommended fix:
When to override:

init-file-wrong-location

Recommended fix:
When to override:

license-missing

Recommended fix:
When to override:

missing-dependency

Recommended fix:
When to override:

non-uniform-lib-versions-in-package

The package contains a collection of shared libraries with non-matching versions, for example libfoo.so.0 and libbar.so.1. This means that the sonames in the upstream project will be probably retired individually; libfoo.so.0 will get replaced with libfoo.so.1, without libbar.so.1 being replaced with libbar.so.2. To allow clean and easy retiring of sonames in OpenCSW catalog, each shared library needs to be put in a separate package: libfoo.so.0 goes into CSWlibfoo0 and libbar.so.1 goes into CSWlibbar1. This way, you'll be able to retire each soname individually.

Recommended fix: Use a library-specific package built with something like this:

PACKAGES += CSWlibfoo0
SPKG_DESC_CSWlibfoo0 = Library for foo, libfoo.so.1
PKGFILES_CSWlibfoo0 += $(call pkgfiles_lib,libfoo.so.1)
RUNTIME_DEP_PKGS_CSWlibfoo0 += CSWlibbar1

When to override: Sometimes legacy packages are not yet split and to just make a respin it is probably acceptable to override.

obsolete-dependency

Recommended fix:
When to override:

osrel-tag-not-specified

Recommended fix:
When to override:

perllocal-pod-in-pkgmap

Recommended fix:
When to override:

pkginfo-bad-catalogname

Recommended fix:
When to override:

pkginfo-bad-vendorurl

Recommended fix:
When to override:

pkginfo-description-missing

Recommended fix:
When to override:

pkginfo-description-not-starting-with-uppercase

Recommended fix:
When to override:

pkginfo-description-too-long

Recommended fix:
When to override:

pkginfo-email-not-opencsw-org

Recommended fix:
When to override:

pkginfo-opencsw-repository-missing

The package should have a property OPENCSW_REPOSITORY in the pkginfo pointing to a repository URL for the package build description.

Recommended fix:

Usually this is done automatically by GAR. The syntax of the line is

OPENCSW_REPOSITORY=https://gar.svn.sf.net/svnroot/gar/csw/mgar/pkg/mypkg/trunk@12345

When to override:

This is only necessary when building packages manually or not committed to a repository.

pkginfo-opencsw-repository-uncommitted

Recommended fix:

None needed. The error message goes away once all code changes are committed to the repository, and uncontrolled files are removed. Use 'svn status' to verify that.

When to override:

Do not override this error. Work on your build until it's the last error you see, commit your code and watch your package pass cleanly.

pkginfo-maintainer-name-not-set

Recommended fix:
When to override:

pkginfo-pstamp-in-wrong-format

Recommended fix:
When to override:

pkginfo-version-wrong-format

Recommended fix:
When to override:

pkgmap-question-mark-perms-in-opt-csw

Recommended fix:
When to override:

pkgname-does-not-start-with-CSWpy-

Recommended fix:
When to override:

rev-tag-missing-in-filename

Recommended fix:
When to override:

shared-lib-package-contains-so-symlink

Packages with shared libraries should contain shared libraries only. The .so files are necessary only during the linking stage of compilation, and don't need to be in the library package. They belong to the same package where the header files (.h) are. It can be either a *-devel package, or the main one.

Recommended fix: Move the .so file to the same package that holds the header files. Make sure that the updated package with the shared libraries still works properly. If you want to test the dependent packages (i.e. packages that depend on your CSWlibfoo0), install your updated package on a test host and run checkpkg against the dependents. Consider the following scenario:

  1. The existing dependency is CSWbar → CSWlibfoo0
  2. You move libfoo.so from CSWlibfoo0 to CSWlibfoo-devel
  3. To test, install CSWlibfoo0 on testing9s
  4. On testing9s, run checkpkg against the dependent package in the catalog, e.g. /export/mirror/opencsw/current/sparc/5.9/bar-1.10.9,REV\=2010.07.05-SunOS5.9-sparc-CSW.pkg.gz. If checkpkg doesn't throw the missing-dependency or missing-soname errors, your new CSWlibfoo0 package is OK.

When to override: Some libraries, for example ffmpeg, depend on SONAMES with the .so-ending. It isn't a good practice, but this was the decision of upstream developers and we decided not to change that. As a result, the .so file is actually needed during runtime.

shared-lib-pkgname-mismatch

Shared libraries need to be placed in packages with corresponding names. For example, /opt/csw/lib/libfoo.so.0 needs to be placed in CSWlibfoo0. This idea is based on Debian policy1 and has been discussed on the mailing list2.

If the library name would be confusing due to numbers embedded in library name, a dash can be used to separate the soname version from the library name. For example, libapr-1.so.0.4.2 can be put into CSWlibapr1-0. By default, separators are added between two adjacent numbers, and removed if a number and a letter are next to each other. For example, libfoo.so.0 becomes CSWlibfoo0, and libfoo-1.so.0 becomes CSWlibfoo1-03.

Recommended fix: Suppose your current package is named CSWfoolib and checkpkg is suggesting CSWlibfoo0. Here's what to do:

1. Split out the shared objects and symlinks to a the suggested package. It's important that the package contains the file with the actual data and a file named after the soname.

/opt/csw/libfoo.so.0 → libfoo.so.0.0
/opt/csw/libfoo.so.0.0 → libfoo.so.0.0.1
/opt/csw/libfoo.so.0.0.1

Don't include the libfoo.so file. The .so files are used during compilation and linking and belong to the *-devel packages.

2. Add a dependency from CSWfoolib to CSWlibfoo0, so that every time CSWfoolib gets installed, CSWlibfoo0 gets installed as well.

3. If you want to clean the repository up, file bugs with all the packages that declare a dependency on CSWfoolib, that they need to start depending on CSWlibfoo0.

4. Once no packages depend on CSWfoolib, ask the release manager to remove it from the repository, providing both the pkgname and the catalogname of your package.

When to override: If you want to keep the layout your own way, add an override for this error tag. This policy is there to help you maintain your shared libraries in a clean way. If it isn't helping you, feel free to override this error tag. However, first make sure that you understand this policy; read through the e-mail discussion and/or ask on the mailing list about your specific case.
Whenever you have a better idea for the layout of your package that checkpkg is suggesting. If you have doubts, ask on the maintainers mailing list.

soname-equals-filename

Recommended fix:
When to override:

soname-not-found

This means that a library with the specified SONAME has been marked as NEEDED which could not be found. The usual cause is a missing runpath to the location of the library. This can be checked manually by using ldd -r on the reported library.

Recommended fix: Add the runpath to the library e.g. by using EXTRA_LIB = /usr/openwin/lib
When to override: Sometimes libraries are dynamically opened from within an application that already has the needed libraries linked in. If the resulting binary works as expected there is no need to add the runpath.

soname-not-part-of-filename

Recommended fix:
When to override:

srv4-filename-architecture-mismatch

This error is reported if the contents of ARCH in pkginfo is not the same as the one in the package filename. The package filename has the structure <catalogname>-<version>,REV=<date>-SunOS<release>-<arch>-CSW.pkg[.gz]

Recommended fix: It is considered an error in GAR if this error is thrown as GAR should automatically take care of this.
When to override: There should be no need to override this error.

surplus-dependency

A surplus dependency is a dependency that checkpkg thinks is unnecessary. Checkpkg is very capable at detecting shared library dependencies, but it doesn't understand other reasons why a dependency might be needed. For example, checkpkg isn't able to parse all the shell scripts from your package and determine that gnu awk is a valid dependency.

Why throw this error at all then? The reason is that the previous version of checkpkg suggested dependencies that weren't actually necessary; for example, it would suggest including both gcc-3 and gcc-4 shared libraries. As a result, many currently existing packages declare dependencies that aren't actually necessary. The surplus-dependency error tag was created to help weed out those unnecessary dependencies.

Recommended fix: If the surplus dependency contains just a shared library, checkpkg is most likely right, remove the dependency declaration. On a *-dev package there is usually a problem with the compile-time .so shared library pointing to something different than the version specific shared library e.g. .so.1.
When to override: Any dependencies that you understand, but are not handled properly by checkpkg. Think: CSWperl, CSWbash, CSWawk, CSWsed, etc.

unidentified-dependency

There is a dependency on a package defined that is neither in the catalog checked against nor in the current build.

Recommended fix: This can happen if the package set is built from multiple Makefiles. Then this error does not need to be overridden as the final check on all built packages would not have this error.
When to override: There should be no need to override this error. Checking all generated packages together to remove the error is the far better choice.

wrong-docdir

The license is expected to be in the directory /opt/csw/shared/doc/<catalogname>/. If there is no license the error is not reported.

Recommended fix: Put the license in the correct directory.
When to override: The location is a convention. Please do not override this error.

See also

Footnotes
page revision: 41, last edited: 13 Dec 2011 16:25
EditRate (0)Tags History Files Print Site tools+ Options
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License