Env and Stacks/Projects/SoftwareCollectionsInFedora

What we're trying to solve it here? (the big picture)

This page is in progress
This page contains many thoughts that are being discussed rather than some final resolutions. Everybody who cares about Software Collections in Fedora is welcome to talk to the Env and Stacks working group through mail or the irc meeting.

Software collections are a great technology to deliver and use more versions of package stacks on one system. More info at [1] We want to allow the use of this technology on Fedora by providing a way to build, deliver and install a software collection easily. Eventually users should be able to pick-up a software collection from the list of available in Fedora and build an application from/on/with such a collection. Software collections are only one of the ways to deliver more versions of a stack on one machine. There are other ways (like non-SCL coprs) that may share some of the ideas here.

Open questions

• Q: What does "Fedora Base" actually mean? Is it strictly RPM content that is base for other RPM or non-RPM content? a repository? tags? attributes somewhere in pkgdb?
• Q: How to split packages into rings?
• Q: What distinguishes rings and/or what is "main" fedora? build system? level of support? level of stability/assurance? All together?
• Q: Where does EPEL fit in with SCLs? Using SCLs in EPEL makes sense. But since CentOS will provide SCLs (hopefully) somehow, do we need to have some collectons in EPEL delivered outside of CentOS?
• Q: What does it mean to deliver a collection in a system/repository? deliver an rpm package with a repo file?
• Q: What does "a set of all collections in Fedora" actually mean? Is it ring-N? Is it a product? is it just a repository with collections that share the fact that they are considered officially included in Fedora?

Questions with a proposed answer

• Q: Should we actually consider only SCLs or should we just talk more about "stacks of software" (bundles)?
• A: Maybe we can talk more generally about stacks (scls, coprs, non-RPM stacks...) that have some particular content and are built above some base set of packages.

• Q: What about Centos -- how to handle Fedora and Centos and EPEL -- where to keep what and how to collaborate?
• A: One developer may want to maintain a collection for all -- Fedora/EPEL/CentOS in some cases. In some cases he won't care about all of them. (fixme) We should make it but must not be willing to do so.

Answered questions

• Q: Where does Env and Stacks fit in SCL for Fedora?
• A: To specify guidelines/rules/best practices to build, deliver and use Software Collections in Fedora.

What does working with collections look like (user's PoV)

Basic usage after installing is pretty much defined by scl-utils usage. The bigger issue is with working with repositories.

Questions with a proposed answer

• Q: How packagers and rel-eng will work with the collections:
• A: Partial answer at [Use cases for packager and rel-eng]

• Q: Do we want to allow building of non-scl packages on top of SCL?
• A: Not from Base Fedora, but packages in some outer ring yes.

• Q: Does one software collection mean it is a separate repository?
• A: Repository may either include one collection or all of them. one common repository could be better if we consider only SCL content there. But as soon as we consider also non-SCL content (generally coprs) then we need separate repositories.

How to build and deliver collections in Fedora (packager's PoV)

Open questions

• Q: How to identify part of the Packaging Guidelines valid for SCLs? add a comment into the Guidelines? Link to the specific chapter to not duplicate text?
• Q: Where to report bugs, edit permissions? pkgdb and bugzilla with some adjustments? what granularity do we need?
• Q: how to handle updates? do we want something like bodhi for collections? Or is playground is enough?

Questions with a proposed answer

• Q: Where to keep the sources for a collections
• A: It should be common use case to keep spec files in sync with Fedora. The git repo needs to be assured. Fedora contributors may edit/FAS account integration needed.

• Q: Build system?
• A: Copr with signing?

• Q: Which vendor to use?
• A: fedora (hhorak to check if that already be decided)

• Q: what collections names to use?
• A: whatever people want, since we need to stay compatible with centos/rhel to stay attractive for projects like openshift; rh- prefix means the collection is compatible with what is shipped in rhscl. These collections will be, for example, used by users that want to develop applications for Red Hat Software Collections on Fedora.

• Q: do we want to allow only content from Fedora Base to be used in collections?
• A: Probably not because some collections requirements do not make sense to be included in fedora.

• Q: Reviews of the RPM specs and collections generally?
• A: we require license review for every package, suitability evaluation when moving from playground to some proper/stable place. Some guidelines will be defined specifically for SCLs. Some Guidelines will be required from general Packaging Guidelines, but not all.

SCL Packaging Guidelines [from toshio] based on [from bkabrda]; another [from Marcela]

• Q: If release plan will be detached from Fedora, how/where do we address incompatible changes?
• A: is it enough to document the incompatibility and anounce it in advance?

• Q: Should prefix in collections correspond with vendor part under /opt?
• A: centos/rh/fedora/sclo and other may use different vendor upder /opt. But vendor under /opt should be transparent for depended collections or users. Only name of the collection matters. And name of the collections should be the same for the same collections accross distrubutions.

• Q: What will be the workflow of package maintainer in Fedora/SCL/CentOS/EPEL?
• A: He will want to maintain ideally only one SPEC file and build several package into several systems. Not clear where and if that is possible.

• Q: If we deliver collections by inclusion repository file somewhere -- will it work for build time? Will rpm be able to install all buildtime dependencies?
• A: we may need to adjust/define buildroot where these repositories will be installed (does it work in mock?)

• Q: will we need different content for different Base Fedora versions?
• A: Fedora may contain incompatible changes, so we need to be able to build specifically for each of the release. Ideally all such specs are in sync.

Answered questions

• Q: what directory collections will use?
• A: Using /opt in fedora [ticket]