User:Mmaslano/SCL

Draft for Software Collections aka SCL in Fedora

This draft will contain proposal how to work with SCL in Fedora. Guidelines are currently based on know-how of SCL users.

Preparing the SCL Locally

Role: Packager

Note: For a complete packaging guidelines for SCLs, see Packaging

There are few important things that the packager must consider when creating an SCL:

Creating the SCL Metapackage

Choosing correct SCL name is very important.

Every SCL must have a name, that does not match name of any other package. This is implied by the fact that the SCL metapackage's name is the same as name of the whole SCL. It is therefore not a good idea to name an SCL "ruby", when there is a "ruby" package - the name has to be altered. Packager should include something specific to the SCL (usually a specific version of included library) into it's name. Therefore "ruby193" is a good name for a collection that contains Ruby 1.9.3 or "tcl85_withthreads" if you plan different build options for your collection.

SCL metapackage is a basic building block of every SCL. It defines the %scl macro, which represents the name of SCL.

See SCL Metapackage on instructions for creating the SCL metapackage.

Creating the actual SCL packages

Most often, it is ok to start from a rpm package and modify it.

The packages must properly conditionalize all SCL-specific maros to be both SCL and non-SCL buildable. That means, that rpmbuild -bs foo.spec or fedpkg srpm without the %{scl}-build package installed must yield foo-x-x.srpm. This is crucial for koji, as it needs to be able to create the SRPM in buildroots both with and without %{scl}-build package.

See Packaging for complete guidelines on creating SCL packages.

Preparing Build Infrastructure

Role: Rel-Eng

While the Packager is preparing his packages locally, (s)he can give a list of packages that the SCL will contain to the Rel-Eng. Let's say that the SCL being created is called ruby193 and it should contain these packages: ruby, rubygems, rubygem-sprockets (strip the ruby193- prefix, if present). The SCL is being built for latest Fedora.

The steps that the Rel-Eng has to take are these:

 This part works a little different in local setting and for Fedora. I need to review it with someone who knows more about Fedora tags/targets. Tags and inheritance are currently not correct, also branch might be created differently.

1. Create the dist-git repos/branches - for every package, stripped of the SCL prefix (e.g. not ruby193-ruby, but just ruby) do:

• If the dist-git repo already exists, create a new branch inside it. The branch should be named %{scl}-fedora-(version), so in our example ruby193-fedora-20. Let's say that in our example, ruby and rubygems already have the repositories, so a branch in each of them is created.

• If the dist-git repo doesn't exist, create it - with one branch, named as above (ruby193-fedora-20). In our example, rubygem-sprockets and the SCL metapackage - ruby193 - don't have dist-git repositories yet. Create them as you would for any other package, with one branch named as above (ruby193-fedora-20).

• Note that the only package that has the SCL name in its repository name is the SCL metapackage. The other packages are named normally, without the SCL name - therefore there is not dist-git repo ruby193-ruby, but rather the ruby repository has branch ruby193-fedora-20.

• Also note, that all the repositories, including the SCL metapackage, now have a special branch for this SCL, that they will be built from.

2. Create the proper tags and a build target.

• The tags should be named ruby193-fedora-20, ruby193-fedora-20-updates, ruby193-fedora-20-updates-pending (of course, substitute ruby193 with your SCL name).

• The build target should be named ruby193-fedora-20-updates-pending with build tag ruby193-fedora-20-updates and destination tag ruby193-fedora-20-updates. The inheritance should look as in the below picture (note, that the build tag inherits from the candidate tag - this ensures that the SCL packages with dependencing on each other will be buildable):

TBD

• It is essential that scl-utils-build and ruby193-build (%{scl}-build, more generally) are present in the minimal buildroot for building in ruby193-fedora-20-updates target (both for creating SRPM from SCM, and for the actual build).

• Add the requested packages, prefixed with ruby193- (or generally %{scl}-) to the ruby193-fedora-20 tag (they will therefore get inherited into TBD) - in our example add ruby193, ruby193-ruby, ruby193-rubygems, ruby193-rubygem-sprockets. Adding scl-utils into the same tag might not be needed, because Fedora should always contain the latest version. Do not add the names of the packages without prefix, they are useless.

• The SCL packages must have dist tag set to .f(version) (e.g. .f20). To achieve this, tag a proper version of fedora-release into the TBD tag and add it to the minimal buildroot for creating SRPM from SCM.

Following procedure is automated in tag_scl.sh (must be altered for Fedora, can be obtained from lkocman).

Building in koji

Role: Packager

Building in koji is pretty straightforward, almost everything works as it normally does:

1. Checkout the repo from dist-git (e.g. fedpkg co ruby) and switch to the proper SCL (e.g. ruby193-fedora-20) branch.

2. Import via fedpkg import or do the changes and commit them, then push.

3. Important thing before running the build is to ensure that you don't have any %{scl}-build package installed locally. The reason is quite tricky - when creating SRPM from SCM, koji gets the name of the dist-git repository from your local system. Therefore if you have any SCL metapackage (let's say ruby193-build) installed, the %{scl} macro is defined and koji will try to checkout repository named ruby193-foo instead of foo and will fail.

4. Run the build with fedpkg build. Note, that when building metapackage this way, scl-utils-build must be installed locally, otherwise the spec will be unparsable (still, don't install %{scl}-build).