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

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_CFLAGS = -xnorunpath

EXTRA_CXXFLAGS = -norunpath

• GNU gettext for usage of -xnorunpath
• ltmain.sh patch in GNU gettext

When to override: Sometimes paths 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: If your binary is in /opt/csw/bin or similar, do not override. Try to fix the build instead. Otherwise 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:

catalogname-not-lowercase

Recommended fix: Change the package name to use only lowercase characters after the "CSW" prefix. The catalog name is inherited from the package name in most cases.
When to override: There should be no necessity to override.

catalogname-too-long

The catalog name has been limited to 29 characters as the technical limit of the package name is 32 characters where 3 characters are needed for the CSW prefix. The remaining characters match in a canonical way to the catalog name.

Recommended fix: Shorten the catalog name to 29 characters.
When to override: Please do not override the error as it destroys the canonical mapping between package name and catalog name.

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.

dependency-on-nonexistent-package

This errors indicates that the package depends on a package which is not in the catalog. This usually means that another package from a different build is installed on the host which has not been pushed to the catalog.

Recommended fix: The error can safely be ignored if the currently built package is pushed together with the dependent package as checkpkg will honor all packages in one go.
When to override: Please do not override this error as this will break catalog generation.

dependency-on-stub

This errors indicates that the package depends on a package which has been been renamed or removed.

Recommended fix: Depend on the package with the new package name or remove the dependency of the package has been removed.
When to override: Please do not override this 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

This means the package contains a path that must not be in a package. A prominent example is /opt/csw/man which is disallowed because manpages are located in /opt/csw/share/man.

Recommended fix: Either patch the Makefile to put files in the correct locations or use dynamic moving during the merge phase.
When to override: Please do not override this error.

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-owned-by-building-user

A file in the package is owned by the user that is running the packaging. As the owner of the files in the package should be explicitly set when the prototype is generated this is most likely be an issue of the build environment leaking into the package. This also happens when the package generation runs as root which should be strictly avoided as broken install scripts can harm the running system.

Recommended fix: Do not package as root. If this happens as regular user the issue should be investigated.
When to override: If your packaging user is by coincidence has the same name as a user which is added during package installation as described in CSW Classutils

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

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.

filename-version-does-not-match-pkginfo-version

This means some information information from pkginfo is different the the information from the filename (most likely the date in the REV-stamp).

Recommended fix: A simple mgar repackage should rebuild the pkginfo and fix the issue.

When to override: There is no known use case where it is a good thing to override this check.

forbidden-version-interface-dependencies

The given binary uses a versioned interface that is only available in recent Solaris Release. A lot of base Solaris libraries use symbol versioning to be able to easily extend their public interface while not not upgrading the soname.
For example, at the time of this writing, libc.so.1 provides versioned interfaces SUNW_0.7 to SUNW_1.22.7, the last one added the function asprintf, vasprintf and fdatasync.
As SUNW_1.22.3 interface has been added by the latest Solaris patch, we don't want to use it because it will break the binary for all of our users which didn't yet applied the patch.

Recommended fix: Create a mapfile to explicitely specify which interface you want to use. Here is an example of mapfile content:

libc.so - SUNW_1.22.5 SUNWprivate_1.1;

DISTFILES += mapfile
EXTRA_LD_OPTIONS = -M "$(abspath $(WORKDIR)/mapfile)"

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

This error is thrown if you put an init file into /opt/csw/etc/init.d. For example:

/opt/csw/etc/init.d/devmon

Recommended fix: Move the file to /etc/opt/csw/iniit.d and make sure it works.
When to override: Never.

license-missing

Packages should have a license file in it.

Recommended fix: The license name defaults to COPYING, when the license has a different name it can be changed with

LICENSE = <licensename, e.g. LICENSE.txt>

DISTFILES += COPYING

LICENSE_TEXT = This package is under the same license as Perl
LICENSE_TEXT_CSWmypkg = This package is under a different license

missing-dependency

There are a number of mechanism how checkpkg assumes a dependency should exist. The most prominent one is the check for shared libraries where the binaries and libraries in the package is inspected which libraries are needed. In this case checkpkg is almost always right. Please keep in mind that dependencies must always be direct, even if transitive requirements are met as discussed on the mailing list.

Recommended fix: Add the dependency always for shared library dependencies. In other cases evaluate the cause of the dependency before adding the dependency.
When to override: Do not override dependencies to shared libraries. Some checks inspect the presence of python files or perl programs which require the presence of the respective package for the programming language. As these files are sometimes contributed and not necessary for the core of the functionality the error may be overridden after careful consideration.

no-direct-binding

This error occurs when at least of the binary packaged uses the default way of dynamically binding symbols to libraries, instead of using the more recent direct binding feature of the SUN Solaris Linker.
It has been decided to enable direct binding in all OpenCSW packages as it is the only way to handle library soname upgrade in a seamless and painless way.
You can consult the original proposal for more information.

Recommended fix: You just have to make sure that the -Bdirect option is passed to SUN linker ld during the final link step that produces the binary.
This should be done automatically as mgar exports this option in the LD_OPTIONS environment variable before calling configure and make. You might a bug in the configure script or in the Makefile, or the software packaged simply uses a different build system that doesn't take LD_OPTIONS into account.

If the following command returns nothing for your binary, that means that direct binding has not been enabled and that you should check what is wrong with your gar recipe or with the program build system:

/usr/ccs/bin/elfdump -y /path/to/your/BINARY

It also has been noted that the GNU strip command corrupts the elf section where direct binding information are stored, the .SUNW_syminfo section. Make sure you are using /usr/ccs/bin/strip to strip the binaries. It should always be the case unless you redefined the STRIP environment variable or you added /opt/csw/gnu to the PATH environment variable.

When GNU strip corrupts the binary, you usually have the following elfdump output:

.SUNW_syminfo: invalid sh_info: 0

When to override:

• Enabling direct binding also enables lazy loading which can cause problem with chrooted daemons. You may want to disable direct binding and override the check but the best solution is to disable lazyloading by adding the following line in your Makefile:

EXTRA_LD_OPTIONS = -z nolazyload

• The check might trigger a false positive in some rare cases: some libraries explicitely tell the linker that, for some of their symbol, it shouldn't do a direct binding. If your binary is only linked to the non directly bindable symbols of a library, checkpkg will think that direct binding was not enabled because it will not found even one directly bound symbol.

You can check that easily using the following command:

$(mgar show-buildsys | cut -f1)/bin/check_db_symbols /path/to/your/BINARY

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

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: If not set, set VENDOR_URL
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

This means that the email address entered in EMAIL in pkginfo in the package does not end in @opencsw.org which is mandatory for an official package.

Recommended fix: Get an official email address, talk to board at opencsw.org.
When to override: When you are making package for use at your local site only you can enter any email address you want.

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

The PSTAMP field from pkginfo should have a value of the form <username>@<hostname>-<timestamp>.

Recommended fix: Adjust the PSTAMP.
When to override: When you are building with a foreign build system the PSTAMP may look different. Although while discouraged overriding may be acceptable.

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-

This means you are packaging some python code which by convention should be located in a package with a name starting with CSWpy-.

Recommended fix: This depends on how the package is called upstream. Python modules in general should be named CSWpy-.
When to override: Applications written in Python and prominent Python modules whose upstream name does not start with py- may be put into packages with a name matching the upstream name.

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 policy¹ and has been discussed on the mailing list².

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-0³.

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

Usually a library contains a specific SONAME which should be put in the file being linked against instead of the direct library name, e.g. in a library libfoo.so could be set to SONAME of libfoo.so.0. This allows to always link with -lfoo but register libfoo.so.0 in the resulting binary instead. Usually libfoo.so is a symlink to libfoo.so.0, at a later time libfoo.so.1 could be released and the symlinked switched to libfoo.so.1. This allows easy upgrade of ABI incompatible changes by keeping the linked file while allowing to compile against new versions of the library at the same time.

Recommended fix: Use -h <soname> during linking for a shared library to add the SONAME field. It may also be necessary to rename libfoo.so to libfoo.so.0 and add the symlink from libfoo.so to libfoo.so.0.
When to override: There are rare packages which version in the main library name, most notably libtcl8.5.so which does not use SONAME. In this case it is safe 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:

soname-unused

This means that a library with the specified SONAME has been marked as NEEDED in one binary (executable or library) of the package, however no function or symbol of the library is used by the binary.
This can be checked manually by using ldd -Ur on the reported binary.

There are usually two possible causes:

• several different binaries are included the package and they are linked against the same libraries, even if some of these binaries don't need it. Very often the build system doesn't make a difference between the link options of each binary and links everything against the widest set of libraries.
• there is a problem in the configure script of the program, or in the pkg-config configuration file of one of the dependency of the program, which incorrectly adds unecessary libraries to the linker flags (e.g. -llibrary options).

It should be fixed to avoid unecessary dependencies inside the OpenCSW software stack.

Recommended fix: There are two ways to fix the problem:

1. the easiest way is to make sure the -z ignore option is passed to SUN linker ld during the final link step that produces the binary.
This option prevents the linker from linking the binary against libraries that are not really used. More information can be seen in the Linker and Libraries Guide.

This is often the best solution when multiple binaries are included in a package, because it can be cubbersome to fix the build system.

Normally this should be done automatically as mgar exports this option in the LDFLAGS environment variable before calling configure and make. You might have a bug in the configure script or in the Makefile, or the software packaged simply uses a different build system that doesn't take LDFLAGS into account.
You have then two choices:

• fix the build system so that it correctly takes into account the LDFLAGS environment variable. The advantage is that it will also now take into account any subsequent distribution wide LDFLAGS modification.
• configure or patch the build system to make sure -z ignore option is used.

2. the hardest way is to identify the source of the unecessary linker flags, fix the problem and report the problem upstream or to the opencsw maintainer of the dependency which added the linker flags, as appropriate.
If applied upstream, this solution fixes the problem for everyone and not only for OpenCSW.

When to override: It is not yet clear at that time when overriding is the good solution to this problem, but it is considered ok to override unecessary dependencies on libraries belonging to the core solaris system.

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.

dependency-on-a-nonexistent-package

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

If you override this error and push a package depending on a nonexistent package, you will break the catalog; the catalog generation will stop.

This error might be considered a false positive if your package set is built from multiple Makefiles, so checkpkg ran at package build time does not have a full view of what you're going to insert into the catalog. If this happens, ignore the reported errors at package build time, and submit them all in one go with csw-upload-pkg. If your dependencies are in fact in good shape, csw-upload-pkg will run checkpkg against the full set of packages and the check will pass. No overrides are necessary.

Recommended fix: If you're building a package set from multiple sources, see above. Otherwise, make sure that you're not defining dependencies on nonexistent packages.
When to override: Never.

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

• Checkpkg