OpenSolaris Source Juicer is a web service which allows OpenSolaris community developers to build packages and publish them for review. It is the gateway to the OpenSolaris /pending and /contrib respositories. Here is a list of the packages which have been promoted to /contrib from Source Juicer. To learn more about Source Juicer you can visit the project page.
To summarize, OpenSolaris Source Juicer requires you to submit a spec file and a copyright file along with other files which are necessary to build your package. When these requirements are met, Source Juicer attempts to build a package based on your spec file and publish the resulting package into a /pending repository, where it will be assessed by Approvers. Upon successful completion of review and approval, the package can be promoted into the /contrib repo and made available to the Opensolaris community, as a trusted package. It is also possible to submit a spec file which updates the versions of packages which were previously published to the /pending or /contrib repository.
The Source Juicer video demo page is a good place to look for tutorials demonstrating typical Source Juicer usage.
Getting Started -- The path to the /contrib repository
The purpose of Source Juicer is to provide a path for
software packages to get into the /contrib repository.
This section will explain the ingredients required as well as the
procedure which must be followed in order to build a package and
promote it through the steps into /contrib.
For more information regarding methods and procedures for getting software into OpenSolaris package repositories, see the contributing page of the sw-porters OpenSolaris community.
Whether you are developing a new application or porting existing opensource
software, you may wish to build your software locally before submitting the
spec file and other components to be built by OpenSolaris sourcejuicer.
Therefore, you should have an up to date version of the OpenSolaris operating
system and the OpenSolaris CBE (Common Build Environment) installed.
You can find out how to set up a local Source Juicer build environment
here.
For more detail about the history and other aspects of the OpenSolaris Desktop Common Build Environment (CBE) you can also look here:
http://opensolaris.org/os/project/jds/contributing/building/
Or here:
Creating a Development Desktop on OpenSolaris.
Once you have configured a build environment, you're ready to build a package locally. Once it builds locally, and runs well enough for you to think it is ready to be reviewed as a candidate for the OpenSolaris package repositories, youre ready for the next step, assembling the components of an OpenSolaris Source Juicer package submission.
First, please read the Source Juicer Contrib process and Porting Guidelines.
| Ingredients of a Source Juicer package submission | |
|---|---|
|
|
|
|
|
|
|
|
|
|
To submit a new package entry, a contributor should browse to http://jucr.opensolaris.org and select the submit tab. To make a package submission in Source Juicer's submit facility you must be logged into your OpenSolaris.org account. If you are not already logged in, you will be directed to a login page.
Once you are logged in, you will be redirected to the submit page. This is where you must enter an identifier (label) for your package entry. Then you must specify and submit a spec file,>/A> a copyright file, and any other files necessary to build your package:
At any point after initially submitting the files required to build your package, you may resubmit those files or submit additional files. This may be in response to comments you receive from reviewers or because of mistakes you have spotted with the original submission yourself. Re-submission of files is done from the Review Thread.
At this point your submission will be checked for correct syntax and validated to ensure it contains correct license and package metadata information. An approver can complete this validation process. The progress through validation can be viewed in the package review page.
The build will not proceed unless the spec file and license details have both been validated.
Once your submission is validated, Source Juicer will attempt to automatically build the new package (or update to an existing package). The status of the resultant build job can be viewed in the MyJuicer or Build pages.
(You can read more about Source Juicer's Build Grid here.)
Your job can be in one of four states:
You can also look at the contents of the pkgbuild build log.
It is expected that Contributors, Reviewers and Approvers should
install a package in order to perform some level of testing and provide
useful review comments. To install a package, simply find your package
in
the /pending package catalog and click the Install link.
The OpenSolaris package manager should ask you to add /pending as an
package authority and proceed to install the package.
If for some reason this doesn't work, you may perform the following manual
steps on your OpenSolaris machine:
Once your package has been published into the /pending repository, a submission review thread is created and you will receive notification by email. This thread can be viewed in your MyJuicer page. The review thread is where you can engage with reviewers in order to improve your package and ready it for promotion into the /contrib repository. You can also view other packages under review in the review page.
A
reviewer would go to the [review] input page for your package in
order to make comments or vote on your package:
Once a package receives a positive (+1) vote from two approvers and no negative (-1) votes, it is eligible to be promoted from the /pending repository to the /contrib repository.
Submit new or newly ported software which will be built into candidate OpenSolaris packages.
Watch comments and for this package submission and make any necessary modifications to spec files, patches or source code as the package submission goes through the build, review and approval process.
Assign yourself or a group you belong to as the package maintainer.
NOTE: Important legal notice for employees of Sun Microsystems, Inc
Validate OpenSolaris Source Juicer package submissions
Review submissions. It is expected that the approver will also install packages and undertake some level of functional testing before voting on a package.
Comment on package submissions. If there is something wrong with a package or something missing from a package, the approval should put enough detail in the comments to help the package submitter make the necessary fix.
Vote on package submissions. An approver can vote to approve (+1) or veto (-1) a package.
Approvers can also be process leaders who have the authority to resolve package porting ownership disputes and similar issues.
For more information regarding roles as well as the process for becomming a core contributor, see the Repo Process Roles document.
These file types are accepted in an OpenSolaris Source Juicer package submission:
A spec file is a recipe for building source code into an OpenSolaris package. OpenSolaris pkgbuild (a port of the gnu/linux rpmbuild utility) takes a spec file as input and outputs an IPS package. Pkgbuild is part of the OpenSolaris Common Build Environment (CBE) which has been used by the desktop team for several years.
Spec file naming convention is {package_name}.spec and the Name: field wilthin this specfile should match package_name. For example:
MyProject.spec
Name:MyProject
NOTE:For more a more detailed explanation of how to write a spec file, please read the spec file help page.
A copyright file contains the text of the
license (e.g. CDDL, LGPL, MPL...) for your software component;
Note: the filename should match the spec file's name, but with a
".copyright" extension instead of ".spec" AND
the SUNW_Copyright: value within the spec file should match
this file's name. This is easily achieved using the %{name} macro,
eg:
Spec file SomeProject.spec:
Name:
SomeProject
...
SUNW_Copyright: %{name}.copyright
Patch files specify changes which must be made to the source code.
Patch files must follow the unified diff format (as in the output of
diff -u) format.
Note 1: "-p1" patches are preferred,
which means that the path names in the diff start with the top level
directory of the source tree (see 'man gpatch' for the description of
the -p flag)
Note 2: patch filenames should be in the format:
<Name>-<Number>-<Descriptor>.diff, eg
SomeProject-01-branding.diff
Note 3: Patches should be applied to
the source code in the %prep section, eg (for Patch5):
%prep
...
%patch5
-p1
Include file are rarely needed, but they are available if necessary. Thse are the files which are included into a spec file if pkgbuild encounters the %include directive.
Typically these will be the spec file from the originating community. It would contain the parts of the build recipe that are common to all platforms. The main spec file would access the base spec file by useing the %use directive.
This allows you to submit manpage files which were not available from the community source tarball(s).
These are small, additional sources which are required to build the component but which are not available in the community source tarball(s).