Child pages
  • OpenIndiana Addon Consolidations
Skip to end of metadata
Go to start of metadata

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


  • No labels


  1. Anonymous

    It would be nice if Solaris Studio 12.2 were allowed for building. It has improved support

    over 12u1 for stdcxx. The only problem with 12.2 I'm aware of is discussed in this thread:

    I've used 12.2 exclusively under OI without any problems.

    1. C++ is sort of a minefield because we essentially have four incompatible ABIs: g++/libstdc++, Studio libCrun with the original Rogue Wave STL (the default) or STLPort, and stdcxx. The only one used in Solaris proper is libCrun with Rogue Wave STL (libCstd). stdcxx is attractive but we haven't made a decision as to which additional C++ ABIs to support. Thomas Wagner is trying to sort out how to curb the proliferation of different C++ configurations in spec-files-extra at the moment, so we will be watching how that goes.

  2. Anonymous

    I think that most Open Source software is developed using g++ so this makes it almost impossible to use Studio to compile things like say MPlayer (some bits of it use C++). Maybe people should seriously consider moving away from Studio.