Child pages
  • OpenIndiana Addon Consolidations

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

OpenIndiana Addon Consolidations (DRAFT)

General Notes


  • provide packages of additional software
  • uphold a high quality standard
  • attract new packagers

Organization and Procedures

  • three-tiered approach to software in OpenIndiana, classification in terms of cross-consolidation interdependencies and interface compatibility policies

Oracle and Illumos "core" consolidations

  • external rules
  • cannot add or change public interfaces
    • including the introduction of new interfaces or making consolidation-private interfaces public

OpenIndiana "main" consolidation(s)

  • can have cross-consolidation dependencies on core consolidations
  • can have limited cross-consolidation dependencies on main consolidations
    • this will be a consolidation-specific policy in case of multiple consolidations
  • should not duplicate software in core consolidations
  • new public interfaces will need approval, cannot break compatibility with core interfaces
    • the OIDC approves the introduction of public interfaces
    • consolidation-private interfaces do not need approval although some documentation may be required

OpenIndiana "extra" consolidation(s)

  • can have cross-consolidation dependencies on core, main, extra consolidations
  • can duplicate software in core or main consolidations
  • can introduce new interfaces without approval with technical measures to prevent conflict

Release Process

  • each "main" and "extra" consolidation will have separate development repositories
  • newly added packages will be published to their respective development repository first
  • all packages will be rebuilt for each development release due to cross-dependencies on packages delivered as part of the "core" consolidations
  • the "main" consolidations will be published together with the "core" consolidations, "extra" consolidations will be published in a separate repo which is not enabled by default
  • provide a pending repo which is updated as soon as new packages are added/exsisting packages are updated/removed

Build System

  • currently based on pkgbuild
    • specfile style similar to JDS/SFE/jucr which is already documented well and ensures a low entry barrier for SFE and former contrib maintainers interested to get involved
  • a second buildsystem similar to BSD-ports will be added later
  • the choice of buildsystem will be left to the preference of the package maintainer
  • both buildsystems will publish to the same repos
  • the contribution process and rules for resulting packages will be the same
  • an automatic conversion tool will be provided later


  • three roles:
    • packager
    • contributor
    • core contributor
  • there is an accountability chain: a packager is sponsored by a contributor, a contributor is sonsored by a core contributor, a core contributor is accountable to the OIDC
  • it is desirable to have as many contributors as possible

Process for Sumitting New Packages

  • the included template spec file can be taken as a starting point
  • a packager creates and tests package locally in the defined build environment (a build zone)
  • the packager files a feature request on against OI main or OI extra which includes:
    • a unique name for the package
    • a description of the packaged software
    • a link to the upstream website and source files
    • the specfile and a base-specfile (if applicable)
    • a copyright file
    • patches (if applicable)
    • additional source files (if applicable)
    • man pages for binaries (if not provided by upstream)
  • the submission is reviewed by a contributor who becomes the sponsor for the packager
  • a test build is done in a scratch zone/chroot on the OI build server
  • the resulting package is installed and tested
  • if the package does not conform to the guidelines or building or testing fail, another packager, contributor, or the sponsor add(s) a comment requesting corrections
  • after the sponsor recognizes that all problems have been resolved the package becomes part of the consolidation
  • the sponsors check it into the hg repo and adds the built package to the pending repo
  • if submitters do not respond to comments within 4 weeks a comment is added requesting a response, if there is no response within 7 days the bug is closed

Validation Checklist for Package Submissions

  • the package must be under an approved open source license (
  • if the package includes code covered by known patents it must include a grant from the patent holder allowing royalty-free redistributions (either as part of the license or in form of an explicit statement)
    • otherwise it must be included in the separate "encumbered" consolidation
  • the include copyright file must reflect the upstream license
  • each package must define an %owner macro containing a valid email address of the current maintainer
  • post/pre installscripts should not be used, they will be ignored by IPS anyway
  • if possible, SunStudio 12u1 should be used to compile C/C++ packages, GCC may be used as a fallback solution
  • the package must not not include prebuilt binaries or libraries (due to security and reproducability concerns, firmware is exempted)
  • applications should be linked against shared libraries
  • all files must be installed in locations designated by
  • installed files must respect namespaces and installed files must not conflict with existing packages
    • the "extra" consolidation uses the /usr/oie prefix
  • must be in the appropriate consolidation
  • should only duplicate existing packages in OpenIndiana with justification (e.g. newer library versions might be needed as a dependency)
  • libraries should be provided both as 32-bit and 64-bit versions (see multi-ISA documentation
  • relevant documentation needs to be included
  • all binaries must have a manpage (at least a stub)
  • OpenIndiana-specific technologies should be taken advantage of as feasible (Dtrace, FMA, ZFS, SMF)
  • non-branding patches must be sent upstream

pkgbuild-based packages

FIXME include others

(see also JDS guidelines)



  • each package is either maintained by an single maintainer or group consisting of a maintainer and co-maintainers
  • packagers and contributors can be maintainers

Change of Maintainership

  • maintainerhip can be transferred
    • by the current maintainer
    • when the maintainer is unresponsive (see conditions below) with the approval of the OIDC

Orphaning of Packages

  • packages will be orphaned
    • when the maintainer is unresponsive (see conditions below)
    • when the maintainer gives up maintainership
  • orphaned packages will be announced in a bug report and on the mailing list either by the former maintainer or a core contributor member, if it is not adopted within 7 days it will be removed

Removal of Packages

  • packages will be removed under the following conditions:
    • security issues/grave bugs
      • which cannot be resolved
      • or when the maintainer is unresponsive and nobody is willing to take over maintainership
    • the package is not properly licensed
    • the package has been obsoleted by another version
    • an orphaned package does not find a new maintainer
  • removal of packages must be approved by OIDC



  • anybody
  • can submit packages which need to be reviewed and approved by core contributors
  • can beome package maintainers but updates require review by a contributor
  • can comment on reviews, do testing (important for promotions)


  • a contributor is a packager with experience and sustained contributions
  • has direct access to the hg repo
  • can review and sponsor packages from packagers
  • can update his/her own packages without review

Core Contributor

  • a core contributor is a skilled contributor with broad expertise
  • can update any package without review provided one of the following conditions is fulfilled
    • grave bugs/security flaws are not fixed timely
    • a package causes problems for the lots of consumers or the project as a whole
    • changes are minor and affect a broad range of packages (cleanup/style changes)
  • can sponsor packagers to become contributors
  • can nominate contributors to OIDC to become core contributors
  • can remove packages


  • the OpenIndiana Developer Council
  • makes decisions regarding packaging rules and exceptions from those rules
  • resolves disputes
  • approves core contributors
  • approves ownership changes and removal of packages


From Packager to Contributor

  • in order to become a contributor a packager can apply for sponsorship to an existing contributor
  • the appplying packager is required to have some experience and sustained contributions
    • the sponsor verifies this by reviews and maintainership of packages

From Contributor to Core Contributor

  • in order to become a core contributor a contributor can apply to the OIDC
  • the application should contain a short rationale why he/she wants to become a core contributor and verifiable selection of contributions
  • the OIDC needs to approve with three +1 and no -1

Unresponsive Maintainers

  • in case a maintainer appears unresponsive, a bug is opened requesting a response
  • after every 7 days a comment listing unsuccessful contact attempts is added
  • after 3 weeks it can be request that the OIDC transfer the ownership of the package(s) to the requester or start an oprhaning process