Repository files navigation

Warning

There is no guarantee that packages in this repository build correctly onOmniOS releases earlier thanr151046. If you wish to build on olderreleases, check out thepre-r151046 tag (or thepre-r151038 tag respectivelyif you want to build on releases earlier thanr151038).

The purpose of this document is to introduce building packages for the "OmniOSExtra IPS Repository".

The "OmniOS Extra IPS Repository" offers a simple way for administrators toinstall applications. Like everything else about the OmniOS Community Editionproject, it is a volunteer effort. It is important to keep this in mind whenreading this document.

The "OmniOS Extra IPS Repository" is open to all, anyone may submit a newpackage, or volunteer to maintain an existing or un-maintained package. Nospecial commit privileges are needed andassistance is available if needed.

1. Requirements
2. Create the build environment
3. Create a build directory and its build files
4. Build thehelloworld package

1. Package naming conventions
2. Structure of an OmniOS package
3. Thelocal.mog andlib/mog/global-transforms.mog files
4. Build and run dependencies
5. Configure directives
6. Make directives
7. Linker directives
8. Using your own functions inbuild.sh
9. Creating patches
10. SMF manifests
11. Providing messages at installation
12. Making the source available to the build environment
13. Managing licences
14. Adding package information to the build system
15. The build system's default "IPS Repository"

1. Building packages that share common elements
2. Tips for building libraries
3. Tips for Go packages
4. Tips for Perl packages
5. Tips for Python packages
6. Tips for Rust packages

1. Create a "Pull Request" for the "OmniOS Extra IPS Repository"

1. OmniOS community support channels
2. Recommended reading

The objective of this section is to prepare a build environment and introducethebuild.sh andlocal.mog files. After this, an experimental build can berun with an example package.

1. Requirements
2. Create the build environment
3. Create a build directory and its build files
4. Build thehelloworld package

To create packages for the "OmniOS Extra IPS Repository", the following isnecessary:

• Virtual or physical system running the latest OmniOS release, preferably thelatest"Bloody Release".

• The system should have a minimum of 2GB of RAM.

• "OmniOSExtra Build Tools" This can be installed with the following command:

# pkg install ooce/extra-build-tools

• AGitHub account.

If help is needed with this, please see:https://help.github.com/en/github/getting-started-with-github/fork-a-repo

In a suitable directory, clone the fork of the "OmniOS Extra IPS Repository",that was created in the previous step.

$ git clone github.com/github_account/omnios-extra$ cd omnios-extra

The "OmniOS Extra IPS Repository" consists of the following 4 directories:

In this section, the ubiquitoushelloworld will be packaged for OmniOS.

Before creating any new package, it is necessary to create a newgit branchfor its build files. The reason being, is that when the package is latersubmitted for inclusion into the "OmniOS Extra IPS Repository", only a "PullRequest" from agit branch will be accepted.

Name thegit branch after the package name.

$ git branch helloworld$ git checkout helloworld

To create the build directory for thehelloworld package, create a newdirectory under thebuild directory in the cloned "OmniOS Extra IPSRepository".

$ mkdir build/helloworld$ cd build/helloworld

Every package relies on 2 files to complete a build,build.sh &local.mog.These are created as follows:

$ touch build.sh local.mog$ chmod +x build.sh

Asbuild.sh is abash shell script, it is set as an executable.

Once these empty files are created, the following templates can be used tocreate thehelloworld build files:

#!/usr/bin/bash## {{{ CDDL HEADER## This file and its contents are supplied under the terms of the# Common Development and Distribution License ("CDDL"), version 1.0.# You may only use this file in accordance with the terms of version# 1.0 of the CDDL.## A full copy of the text of the CDDL should have accompanied this# source. A copy of the CDDL is also available via the Internet at# http://www.illumos.org/license/CDDL.# }}}# Copyright YYYY your name/organisation. ../../lib/build.shPROG=helloworldVER=0.1PKG=ooce/application/helloworldSUMMARY="Hello, World! - A global salutation"DESC="Hello, World! is a computer program that outputs the\message 'Hello, World!'"set_arch 64set_mirror"https://pbdigital.org/ips-src/"set_checksum sha256"c6bdfebe1b9f27fc90a24348aa3492558d2bf5b0e2c366a9b6f9ec9f50b74917"# create package functionsinitdownload_source$PROG$PROG$VERprep_buildbuildstrip_installmake_packageclean_up# Vim hints# vim:ts=4:sw=4:et:fdm=marker

## This file and its contents are supplied under the terms of the# Common Development and Distribution License ("CDDL"), version 1.0.# You may only use this file in accordance with the terms of version# 1.0 of the CDDL.## A full copy of the text of the CDDL should have accompanied this# source. A copy of the CDDL is also available via the Internet at# http://www.illumos.org/license/CDDL.# Copyright YYYY your name/organisationlicense LICENCE license=CDDL

The contents of these files will be discussed thoroughly in the"OmniOS Extra Build System" section.

For thehelloworld package, the abovebuild.sh &local.mog templates areenough to build the OmniOS package.

In fact, for a robust program liketcpdump,thebuild.sh was not much more complicated than the above templates. A lot ofknowledge of the build system can be gained browsing the variousbuild.shfiles in thebuild directory.

From the currenthelloworld directory, thehelloworld package can be builtfrom thebuild.sh as follows:

$ ./build.sh

Note: No special privileges are need to create a package from the build system. Nor is it advised to create packages as theroot user.

This will build thehelloworld package, through all its various stages,terminating with the publishing of thehelloworld package.

The default "IPS Repository", for the build system, that all packages will bepublished to, resides at the root directory of the cloned "OmniOS Extra IPSRepository". The root directory of this default "IPS Repository" is namedtmp.repo.

It is a good idea to install the package, to see the full process of the build system.

First, the build systems "IPS Repository" needs to be imported on the local system. This can be done by importing thetmp.repo as a secondary "OmniOS Extra IPS Repository". This can be achieved from thehelloworld directory as follows:

# pkg set-publisher -g ../../tmp.repo local.omnios

Next, all that is needed, is to install the package:

# pkg install helloworld

To verfify the complete build process, run thehelloworld program.

$ helloworldHello, World!

To gain more control over the build procedure, many options have been added to thebuild.sh script. The following table displays these options:

Now is a good time to try out some of these options whilst building thehelloworld package.

To uninstall thehelloworld package and also remove the package from the "IPS Repository", issue the following commands from thehelloworld build directory:

# pkg uninstall helloworld# pkgrepo -s ../../tmp.repo remove helloworld

This concludes the introductory section. Next, much finer details of the "OmniOS Extra Build System" will be explored.

The "OmniOS Extra Build System" is a framework designed as a convenient and standardised manner to build IPS Packages for OmniOS. It is highly recommended to readPackaging and Delivering Software with the Image Packaging System, to fully understand the finer details of the "OmniOS Extra Build System".

The main engine behind the "OmniOS Extra Build System" is thelib/functions.sh file. In this section, a best effort has been made to describe in detail the workings of the build system, however, if certains details have not been described sufficiently, it is advised to look at the code oflib/functions.sh, as well asPackaging and Delivering Software with the Image Packaging System, to fill in the necessary gaps.

1. Package naming conventions
2. Structure of an OmniOS package
3. Thelocal.mog andlib/mog/global-transforms.mog files
4. Build and run dependencies
5. Configure directives
6. Make directives
7. Linker directives
8. Using your own functions inbuild.sh
9. Creating patches
10. SMF manifests
11. Providing messages at installation
12. Making the source available to the build environment
13. Managing licences
14. Adding package information to the build system
15. The build system's default "IPS Repository"

Searchdoc/baseline for a list of package categories, to determine which best fits the package that is being built.

Simple packages that do not include sub-directories such asinclude,lib &share can be installed directly into the root/opt/ooce directory.

This can be done by omiting the--prefix= option in theCONFIGURE_OPTS directive ofbuild.sh.

Other more complex packages should be installed under the/opt/ooce/ directory. For example the PostgreSQL server is installed to/opt/ooce/pgsql-12

Further, the version number of the package should not be included unless more than one version of the software is being packaged.The naming scheme withapplication-x.y symbolises that the application install directories contain a major version number. Meaning bugfix only releases would replace a previous version, but a new major version would NOT necessarily replace an existing one. Meaning you could install multiple versions of perl of python or even some obscure tool in parallel. The mediated symlinks allow you to choose the default version, but the other versions would still be accessible by using a direct path.

The "OmniOS Extra Repository" contains prime quality packages to enhance your OmniOS system. The packages make full use ofSMF and adhere to the/opt package structure. There is a separate "OmniOS Extra Repository" for each release of OmniOS.

Refer todoc/framework for an overview of the build framework,descriptions of the various variables discussed below, and the functionsand hooks which are available.

Thelocal.mog file is a way to transform package manifests programatically.This allows you to transform the contents of the package in reliable andrepeatable ways. IPS usespkgmogrify to achieve these changes.

In thelocal.mog file it is possible to change ownership and permissions onfiles, drop certain files from a package, make sure certain files do not getoverwritten with newer versions. It also allows the creation of users andgroups and even to adjust system services when a package has this requirement.

From thebuild.sh you can pass variables tolocal.mog with the followingdirective:

XFORM_ARGS="    -DOPREFIX=${OPREFIX#/}    -DPREFIX=${PREFIX#/}    -DPROG=$PROG    -DVER=$VER"

This allowslocal.mog to read in these variables, and later in the buildproccess, forpkgmogrify to make transformations upon them.

An example of transformations possible are as follows:

group groupname=$(PROG) gid=86user ftpuser=false username=gitea uid=86 group=$(PROG) \    gcos-field="Gitea - git with a cup of tea" \    home-dir=/var/$(PREFIX) password=NP<transform path=etc/$(PREFIX) -> set owner $(PROG)><transform path=etc/$(PREFIX) -> set group $(PROG)><transform file path=etc/$(PREFIX) -> set mode 0600><transform file path=etc/$(PREFIX) -> set preserve true><transform dir path=var/$(PREFIX) -> set owner $(PROG)><transform dir path=var/$(PREFIX) -> set group $(PROG)><transform dir path=var/$(PREFIX)/data -> set mode 0700><transform dir path=var/log/$(PREFIX) -> set owner $(PROG)><transform dir path=var/log/$(PREFIX) -> set group $(PROG)>

All these directives will be processed via thepkgmogrify utility.

The first is of particular interest as it creates a new user and group for thesystem.

Following this, is mainly setting ownership and permissions on files.

However of note, the line withset preserve true tells the build system notto overwrite files in the corresponding directory. In this case, old files willbe left untouched and new files will be added with the prefix.new

It is beyond the scope of this document to describe in full detail the workingsof howpkgmogify deals with thelocal.mog file, therefore it is recommendedto read in detail Chapter 8 ofPackaging and Delivering Software with the Image Packaging System,to best take advantage of thelocal.mog file.

The "Omnios Build System" will automatically apply a number of transformationsto a package being created via thelib/mog/global-transforms.mog file. It isrecommended to study this file to appreciate, which changes are being made.

Insert the following intobuild.sh to define the necessary programs tocomplete the build process.

BUILD_DEPENDS_IPS+="    ooce/package/name1    ooce/package/name2    ooce/package/name3..."

Anything from the base install or the meta packagesextra-build-tools&omnios-buildshould not need to be included.

If a package dependency is required to build the package but is not necessaryto install the package, this can be dropped when the software is packaged, viaafinal.mog.

Include the package as normal inBUILD_DEPENDS_IPS directive and then use thefollowing in thebuild.sh:

make_package local.mog final.mog

Also, include afinal.mog file in the base of the package directory, withcontents similar to below:

# Remove the automatically detected 'require' dependencies.# Optional dependencies have already been explicitly added.<transform depend type=require fmri=.*(?:mariadb|postgresql) -> drop>

For an example seehere.

Almost all run dependencies should be auto-detected. It's better to let thishappen than to hard code it. If it is absolutely necessary to define rundependencies, the directive that is placed inbuild.sh is as follow:

RUN_DEPENDS_IPS+="    ooce/package/name1    ooce/package/name2    ooce/package/name3..."

Default configure flags are set in thelib/config.sh file. These may beoverridden or appended to, with theCONFIGURE_OPTS directive. An examplefollows:

CONFIGURE_OPTS+="    --prefix=$PREFIX    --sysconfdir=/etc$PREFIX    --localstatedir=/var$PREFIX    --with-lockfile=/var$PREFIX/run/$PROG.lock    --with-logfile=/var/log$PREFIX/$PROG.log    --enable-openssl"

These will be applied to theCONFIGURE_CMD forboth 32 and 64 bit builds.

Architecture independent configure flags may also be set with theCONFIGURE_OPTS[i386] andCONFIGURE_OPTS[amd64] directives.

Make directives may also be set and overridden inbuild.sh. Follows arepossible use cases:

MAKE_INSTALL_ARGS="    COMMAND_OPTS=    INSTALL_OPTS="

MAKE_INSTALL_TARGET="    install    install-commandmode    install-config"

Like theCONFIGURE_OPTS directive, these apply toboth 32 and 64 bitbuilds.

Architecture independent configure flags may also be set with theMAKE_INSTALL_XXXXXX_32 andMAKE_INSTALL_XXXXXX_64 directives.

lib/functions.sh can provide a working example of how these directives areapplied.

CFLAGS/LDFLAGS directives may also be set inbuild.sh. Follows are possibleuse cases:

CFLAGS+=" -O3 -I$OPREFIX/include -I/usr/include/gssapi"CXXFLAGS[i386]+=" $CFLAGS ${CFLAGS[i386]} -R$OPREFIX/lib"CXXFLAGS[amd64]+=" $CFLAGS ${CFLAGS[amd64]} -R$OPREFIX/lib/amd64"LDFLAGS[i386]+=" -L$OPREFIX/lib -R$OPREFIX/lib"LDFLAGS[amd64]+=" -L$OPREFIX/lib/amd64 -R$OPREFIX/lib/amd64"

Like theCONFIGURE_OPTS directive, the directives without the architectureprefix, apply toboth 32 and 64 bit builds.

Architecture independent configure flags have also been set in the aboveexample with theXXFLAGS[i386] andXXFLAGS[amd64] directives.

lib/functions.sh can provide a working example of how these directives areapplied.

Sometimes it is not possible for the build system to cater for all events, whenbuilding a package. However, withinbuild.sh, it is possible to createfunctions to deal with situations as they arise.

For example, when building a package that has no./configure ormakeprocesses, it is possible to override the main build function as follows:

build() {    logcmd $MKDIR -p $DESTDIR/$PREFIX/nagios/nrdp || logerr "mkdir"    logcmd $CP -r $TMPDIR/$BUILDDIR/server/* $DESTDIR/$PREFIX/nagios/nrdp \        || logerr "cp -r server failed"}

In the above example, the package being built is fromPHP source code. Thereis no./configure ormake processes and the contents can simply be copiedinto the$DESTDIR and then packaged by the build system.

This is a case of overriding a function, however it is also possible to createany functions that are necessary and place them in the right order amongst the"build functions" of thebuild.sh file.

The best source for discovering more about using your own functions, is tobrowse thebuild.sh of other packages.

If it is neccessary to supply patches for the build to complete, these go inthe sub-directorypatches of thebuild/package-name directory.

Generally, one patch should be created for each functional change.. Thefollowing command should be sufficient to create a patch.

$ gdiff -wpruN '--exclude=*.orig' a~/ a/ > description-of-patch.patch

The patching may take place in thebuild/package-name/tmp directory, howeverthe final patches must be transferred to thepatches directory.

The filename of the patch should then beecho'd into a file namedseries,that resides in thepatches directory. The fileseries, is used by thebuild system to apply the patches that are listed in this file. This is done inthe order of the patches listed, so care must be taken, to list patches inorder, as necessary for the build to complete,

$ echo description-of-patch.patch >> series

To ensure the patches are in the standard format for the build system, it isadvised to run an automatic re-base. This can be achieved with the followingcommand:

./build.sh -Pxx...Checking for patches in patches/ (in order to re-base them)Re-basing patches--- Applied patch Makefile.patchChecking for patches in patches/ (in order to apply them)Applying patches--- Applied patch Makefile.patchTime: ooce/application/package-name - 0h0m4s

The output from the command demonstrates that the patches have been re-basedcorrectly.

The "Service Management Facility" (SMF) replacesinit.d scripts in OmniOS(and other illumos based distributions). SMF creates a unified model forservices and service management.

If it is neccessary to include an SMF manifest with the package, the associatedManifest &Method files should be placed in thefiles sub-directory ofthebuild/package-name directory.

It is preferably, however not always possible, that only aManifest fileshould be included.

Once the associated SMF files have been placed in thefiles sub-directory,thebuild.sh can be instructed to process these files with the followingdirective:

install_smf application $PROG.xml application-$PROG

This should be placed after the "build function" declarations and before themake package declaration.

It is beyond the scope of this document to describe in full detail the workingsof SMF, therefore it is highly recommended that you download and read"Management of Systems and Services with Solaris Service Management Facility".

When providing a package which requires manual integration steps, it may benecessary to inform the end user of this situation. IPS has a facility todisplay a message during package installation to inform the end user of anyimportant considerations that should be taken.

This is done by creating a text file and placing it in thefilessub-directory of thebuild/package-name directory. An example text file thatinforms an end user, that they must read the installedIMPORTANT.txt file,would be similar to the following:

------------------Installation Notes------------------For instructions on how to configure and integratethis program with the system, please read/opt/ooce/package-name/share/IMPORTANT.txt------------------

Once thisREADME file has been placed in thefiles sub-directory, thebuild.sh can be instructed to process this file with the following directive:

add_notes README

This should be placed after the "build function" declarations and before themake package declaration.

The omnios-extra build system has a mirror athttps://mirrors.omnios.org/ thatmaintains current source tarballs and checksums. It uses these to build itspackages. In the early stages of a build, this source tarball will not beavailable on the OmniOS mirror, and will be need to be made available for thebuild process.

The easiest way to do this is to usebuild.sh's-M option to temporarilypoint at either the original distribution site, or to a temporary directory.

For example the source tarball for "Apache httpd 2.4.43" is available at themirror:https://downloads.apache.org/. Thereforebuild.sh can be run as:

$ ./build.sh -M https://downloads.apache.org/

or, if you downloadhttpd-2.4.43.tar.bz2 and place it in/tmp/apache:

$ ./build.sh -M /tmp

If the download fails, look atbuild.log to determine the pathnames thatwere tried, and adjust accordingly.

The mirror can also be changed permanently inlib/site.sh.

The above will be sufficient if the accompanying sha256 checksum file isavailable in the same directory as the tarball.

If the checksum is not available, this can be included in thebuild.sh withtheset_checksum directive. For example, had the "Apache httpd 2.4.43"checksum file not been available, the followingset_checksum should be set:

set_checksum sha256 "a497652ab3fc81318cdc2a203090a999150d86461acff97c1065dc910fe10f43"

If the source tarball is on github, the following directive should be used:

set_mirror "$GITHUB/apache/$PROG/archive"

Further in thebuild.sh file, thedownload_source directive should be asfollows:

download_source $VER

NOTE: Downloading from GitHub always seems to be a moving target. See theExceptional cases regarding source tarballs section to help troubleshootdownload_source problems.

GitHub does not supply checksums for downloaded archives, so this can be workdaround with the following directive:

set_checksum "none"

Sometimes the source tarball is not in a standard format and the argument tothe directive,download_source, will need to be edited accordingly.

Sometimes the tarball will extract to an un-expected directory. For example,sometimes a tarball named$PROG-$VER.tar.gz may extract to a directory named$PROG-$PROG-$VER.

In this case, use theBUILDDIR directive, as follows:

set_builddir "$PROG-$PROG-$VER"

Sometimes the source directory, where theconfigure script lies will not bewhere it is expected. For example, theconfigure script may not be in theroot of the$PROG-VER/ directory, but instead in$PROG-VER/$PROG/.

In this case. the aboveset_builddir should also take care of this.

All packages must be bundled with their respective licence. To add a licence tothe package being built, the licence must be included in thelocal.mog file.This is generally always the last line of text in thelocal.mog file andappears as follows:

license COPYING license=GPLv3

The utility,tools/licence, is used to determine the specific type oflicence. To manually determine the licence that is bundled with the package runthe following:

$ tools/licence build/package/tmp/path/to/LICENCE

This will return the licence type.

Licence definitions can be viewed indoc/licences.

These definitions cover most open source licences.

If the licence is not detected, it is possible to use theSKIP_LICENCESdirective, followed by the licence type, inbuild.sh. For example:

SKIP_LICENCES="Sleepycat"

In this case, it is possible to use theSKIP_LICENCES directive as follows:

SKIP_LICENCES=Various

The corresponding entry in thelocal.mog would appear similar as follows:

license LICENSE.adoc license=Variouslicense GPL-3.0.txt license=GPLv3

It is possible to write a function inbuild.sh, to extract licenceinformation in the source, if it is available.

Anexample function to extract the licence is as follows:

extract_licence() {    logmsg "-- extracting licence"    pushd $TMPDIR/$BUILDDIR > /dev/null    sed '/^$/q' < $PROG.c > LICENCE    popd > /dev/null}

The licence may then be determined by thetools/licence utility.

As a last resort, you may consider modifying the licence definition pattern indoc/licences.You will need to let the maintainers explicitly aware of anychanges to this file.

To keep the "OmniOS Build System" up-to-date, new packages need to be added tofiles in thedoc/ directory. This is intuitive and can be achieved by simplybrowsing the files that need to be changed and then edit according, withdetails from the package that is being added.

The files that need editing are:

• doc/baseline
• doc/packages.md

The default "IPS Repository", for the build system, that all packages will bepublished to, resides at the root directory of the cloned "OmniOS Extra IPSRepository". The root directory of this default "IPS Repository" isnamedtmp.repo.

The build systems "IPS Repository" may be imported on the local system. This isdone by importing thetmp.repo either as a secondary "OmniOS Extra IPSRepository" (but in that case the signature-policy must be set to ignore),or a local.omnios publisher can be added. This can be achieved as follows:

# cd /path/to/github/repos/omnios-extra/lib/# cp site.sh.template site.sh

Change the line that defines PKGPUBLISHER :

diff site.sh site.sh.template12c12< PKGPUBLISHER=local.omnios---> #PKGPUBLISHER=extra.omnios

Then add the publisher :

# pkg set-publisher -g /path/to/github/repos/omnios-extra/tmp.repo local.omnios

With this set, the list of publishers should look similar to the following:

$ pkg publisherPUBLISHER                   TYPE     STATUS P LOCATIONomnios              origin   online F https://pkg.omnios.org/bloody/core/local.omnios        origin   online F file:///path/to/github/repos/omnios-extra/tmp.repo/extra.omnios        origin   online F https://pkg.omnios.org/bloody/extra/

1. Building packages that share common elements
2. Tips for building libraries
3. Tips for Go packages
4. Tips for Perl packages
5. Tips for Python packages
6. Tips for Rust packages

When building a package for software that has many components, it may arisethat the software should be split into separate packages. This presents aproblem, when these packages share common elements, for example; the same useror directory structure.

The way to deal with this is to create a "Common Package" that the otherpackages can share.

A common package is simply a.mog file placed in the build directory of themain package that you are building. For example, theNagios package, a.mogfile namednagios-common.p5m is placed in the main build directorybuild/nagios. This file details the common elements shared with all the otherNagios packages.

For the build system to recognise this file, thisCommon Package should beaddedonly to thedoc/baseline file. This should not be added todoc/packages.md.

Examining the contents ofnagios-common.p5m and otherxxxxxx-common.p5mfiles should give you a better understanding to contributing these types ofpackages.

Building libraries follows the same outline as building packages, however thereare a few extra considerations that need to be applied.

Libraries are built for both 32 & 64 bit architectures. This just requiresomiting theset_arch 64 directive from the standardbuild.sh file, that hasbeen demonstrated in the "Create a build directory and its buildfiles"section.

If a library installs 32 bit binaries, it is necessary to drop these beforebuilding the package. This can be set in thelocal.mog file, of the librarybeing built.

This should be possible to achieve, with a statement in thelocal.mog file,similar to the following:

# Drop 32bit binaries<transform path=$(PREFIX)/s?bin/i386 -> drop>

Similar to how information is added todoc/... files, when building astandard package, library packages need also to add information to the metapackageextra-build-tools. Therefore thebuild/meta/extra-build-tools.p5mfile will need editing.

The complete list of files that need editing are:

• build/meta/extra-build-tools.p5m
• doc/baseline
• doc/packages.md

Coming Soon! In the meantime,browse the build scripts of GO packages in the repository.

Coming Soon! In the meantime,browse the build scripts of Perl packages in the repository.

Coming Soon! In the meantime,browse the build scripts of Python packages in the repository.

Coming Soon! In the meantime,browse the build scripts of Rust packages in the repository.

• Make sure that the package has been added todoc/baseline

• Make sure that the package has been added todoc/packages.md

• If the package is a library, make sure that it has been added tobuild/meta/extra-build-tools.p5m

Once work has been completed for a new package, thegit branch will be neededto be pushed to the fork of the "OmniOS Extra IPS Repository" that was createdin thefirst section.

The procedure to update the fork is as follows:

git add *git statusgit commit -m 'name of package and version number'git push --set-upstream origin `git-branch`

After the initial commit of thegit-branch has been uploaded, it is possibleto omit the--set-upstream option from subsequent updates. This isdemonstrated below:

git push origin `git-branch`

Viewing the new branch online athttps://github.com, it is now possible tocreate a new pull request. To the right of the "Branch" menu, click "New pullrequest" to submit the new package to OmniOS.

If there have been commits upstream on the original master, after cloning thefork, it is necessary to ensure that the local repository is up-to-date withthe remote master. This is done by first updating the local repository that hasbeen cloned from the fork, and then, updating the fork with the newly updatedlocal repository.

First determine if the upstreamomniosorg/omnios-extra repository is set as aremote.

git remote -v

If the upstreamominosorg/omnios-extra repository is not set, add this withthe following command:

git remote add upstream https://github.com/omniosorg/omnios-extra.git

Now confirm that the remote upstreamominosorg/omnios-extra repository isset.

git remote -v

To pull all the data from the remote into the local repository. Use thefetchandmerge subcommands. Before doing this, check that the current branch isset tomaster.

git branchgit checkout mastergit fetch upstreamgit merge upstream/master

git fetch only downloads new data from a remote repository - but it doesn'tintegrate any of this new data into the working files.

git merge is where the fetched data is pulled into the working files.

After executing the above commands only the local repository will be up-to-datewith the remote upstreamomniosorg/omnios-extra repository.

Once the local repository is up-to-date, it is recommended to push this localrepository to GitHub so that the fork ofomniosorg/omnios-extra is alsoup-to-date.

git push origin master

1. OmniOS community support channels
2. Reccomended reading

• Gitter: Connect to the web-basedchat room on Gitter.
• IRC: Join the#omnios channel on Libera.
• Mailing list: general discussion and queries, please subscribe to theomnios-discuss mailing list.

• Packaging and Delivering Software with theImage Packaging System
• Management of Systems and Services with Solaris Service Management Facility