From Fedora Project Wiki

< User:Mmaslano

Revision as of 11:12, 27 August 2013 by Mmaslano (talk | contribs) (Created page with "= DRAFT for Software Collection in Fedora = Working group: mmaslano, bkabrda, langdon (long time users, early adopters) Reviewer of proposal (user side): msuchy (as previous ...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

DRAFT for Software Collection in Fedora

Working group: mmaslano, bkabrda, langdon (long time users, early adopters)

Reviewer of proposal (user side): msuchy (as previous member of project using collections)

Reviewer from FPC: toshio


In past we couldn't update some components as fast as we wanted because some packages would be broken. On the other hand, sometimes we did update to the latest version and broke various packages -- for example, Puppet. Fedora moves too fast for some developers, but Fedora should also give developers opportunity to stay longer on older/stable versions of their preferred languages by allowing Software Collections (scl).


Software Collections (scl) have been already tested on various packages or sets of packages - gcc, ruby&rails, mysql/mariadb, eclipse and many more. Some projects like OpenShift or Foreman are already using scls for their development and for packaging of their projects.

Homepage of project and testing repositories:

Inclusion of collections in to Fedora

Fedora package reviews could be turned into SCL package reviews using the same process as is used for review of any "normal" new package. We might even be able to use the same ticket for review, only the tag would differ. All SCL packages would still have to adhere to Fedora Packaging Guidelines + there will be a special set of guidelines for SCL, draft is at (Most of it should be already included in [docs] from Documentation team).

Tooling for packaging/reviews

spec2scl can turn many packages automatically from rpms to scl-aware rpms

FedoraReview tool will have a plugin to check scl sanity; part of this checking will be done by scl part of rpmlint (see below)

rpmlint will also have a plugin for checking of scl soon.

Only stable collections should be included in Fedora repositories. Let's say the stable are those used by other projects (Puppet). We don't plan to have dozens of Ruby&Rails collections in Fedora. "Unstable/Rawhide" collections might have some place, where they can live before being switched into "stable" - perhaps leveraging COPRs similar to PPAs. However, we don't wish to address this use case at this time.

Establish SCL SIG - members will mark collections as "stable" - i.e. properly packaged, not conflicting with other collections, etc...

Naming of collections - prefix and name of collection is very important. Every collection which goes into Fedora is reviewed by SCL SIG. It might be done in bugzilla ticket and marking collection by some special keyword - TBD.

Life cycle - collection can live longer than 6 months. The life cycle doesn't have to be defined strictly, it wil be based on needs of dependent projects.

Example: OpenShift would like to stay on Ruby 1.9.3 & Rails 3.2.8, the collection will be maintained by Ruby & Rails collection maintainer as long as collection is needed. In case maintainer loses interest, it could be still maintained by projects using the collection. Orphaning of a collection must be announced on software-collection or fedora-devel list.

Technical details/Workflow

Developers can prepare their collections in mock. Following changes are needed in Fedora infrastructure:

  • buildroot - minimal buildroot must contain scl-utils-build and collection meta-package, which gives name and prefix to the collection .
  • branch - add properly conditionalized macros into new branch based on branch with wanted version. Another possibility might be to have macros in rawhide branch, but it might be hard to do for some packages (Perl, Ruby, MySQL).
  • build mechanism - fedpkg build should be able to build collection properly if a branch has defined buildroot with scl and meta-package.
  • security tracking/handling should be done as for standard packages (packages will have their components in BZ, SRT will file bugs for them, too). We will have to keep the number of collections in Fedora reasonably low to have enough engineering resources.

Guidelines, Howtos

Documentation for users and packagers:

Workflow for packagers and relengs:

SCL packaging guidelines draft: