Package splits

Upstream packages are split into separate packages for installation.
The following package types exist:

  • Runtime Package (CSWpkgrt pkg_rt)
    • Runtime packages contain the files which are necessary to use the package as dependency for another package. Libraries do not have corresponding runtime packages, as the purpose of the library is to provide this functionality already.
  • Developer Package (CSWpkgdevel pkg_devel)
    • Developer packages contain header files, pkgconfig-files, api manpages and documentation relevant to developers.
  • Documentation Package (CSWpkgdoc pkg_doc)
    • Documentation packages contain documentation, but NOT manpages. Manpages always belong to the base package with the exception of developer manpages. The documentation package also must not contain developer documentation.
  • Base Package (CSWpkg pkg)
    • The base package contains all the rest.

Splitting off runtime- and developer packages is mandatory.

Why are packages split?

There are multiple reasons why packages are split:

  • To minimize the size of the installed software, both in terms of megabytes and number of files
  • To have a clean installation of the software (no developer files on deployment machines)

What are the drawbacks?

  • Extra work for maintainers. Separating out the devel files the automated way usually works fine, but the maintainer still needs to look for caveats such as devel packages which aren't ARCHALL, or files that aren't correctly assigned to packages.
  • It's currently common that the GAR builds don't have the build requirements set correctly. When setting up a new build environment, a person trying to build packages with GAR is likely to be frustrated by missing header files even though GAR says that all the build dependencies are installed. The correct setting of prerequisites could be automatically verified with a clean-room autobuild system.
  • Many more packages to manage
  • No space saving when only runtimes used, which is in most cases.
  • It's a pain for the developer to know to install the -dev packages. Not all packages naturally have dev parts and it's not possible to tell if it's missing or never exists (oh great, lets have empty packages where none is needed to keep the system symmetric and avoid all confusion). This could be leveraged if pkg-get/pkgutil would have a "devel=1" switch which would always look for additional *_devel packages and install them automatically
  • I always install "full" OS (because it's saves any effort when I later find something is missing) so there is no problem with finding headers on the system.
  • Solaris has lots of files that are never needed. Doesn't make it right but the user tolerates it, assuming a true user even notices.
  • CSW wastes space in many ways, this isn't the most significant. Packages are about package deals and a one size fits all approach might be best, ie, the user accepts extra bytes in exchange for a shared system.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License