From FedoraProject

Jump to: navigation, search


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).


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.

Every collection will be presented as Change in new release of Fedora. FESCo would review it as standard feature. Detailed Description - description of the collection, for which purpose was collection prepared. For example Ruby collection was done for Puppet, so no ABI changes, which would harm puppet. Also proposed life time must be mentioned here e.g. SCL will be supported at least two releases of Fedora.

Naming of collections - prefix and name of collection is very important.

Life cycle - collection can live longer than 6 months. The life cycle doesn't have to be defined strictly, it will 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.

Packagers can use various tools for packaging collections.

Stable Collections

Stable collection should provide something needed for Fedora. Let's say:

  • stable version of language used by many projects (ruby193, python2)
  • set of packages based on collection

Obsoleting Collections

Maintainer must warn users on devel mailing list, (s)he doesn't plan to support collection X after release of Fedora-Y. If someone else was interested in maintenance, he could take ownership of such collection.

Technical details/Workflow

Workflow was already defined for projects already packaged as scl, but it must be also defined for Fedora

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:


mailing list: