From Fedora Project Wiki
Line 37: Line 37:


* Q: How packagers and relengs will work with the collections:
* Q: How packagers and relengs will work with the collections:
* A: Partial question at [[https://fedoraproject.org/wiki/User:Mmaslano/SCL|Use cases for packager, rel-eng]]
* A: Partial answer at [[https://fedoraproject.org/wiki/User:Mmaslano/SCL Use cases for packager and rel-eng]]


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


* Q: Does one software collection means it is a separate repository?
* Q: Does one software collection means 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.
* 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) ==
== How to build and deliver collections in Fedora (packager's PoV) ==

Revision as of 12:29, 7 January 2015

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

Warning.png
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 great technology to deliver and use more versions of package stacks on one system. More info at [1] We want to allow to use 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 for such a collection. Software collections are only one of the ways to achieve delivering 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 means main fedora? build system? level of support? level of stability/assurance? All together?
  • Q: Where EPEL fits here with SCLs? Using SCLs in EPEL makes sense. But since CentOS will provide SCLs hopefully somehow, do we need to have some collecitons in EPEL delivered outside of CentOS?
  • Q: What it means to deliver collection in a system/repository? deliver rpm package with a repo file?
  • Q: What actually will mean a set of all collections in Fedora? Is it the ringX? 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 stack 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.

How the work with collections will 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: Do we want to allow build non-scl packages on top of SCL?
  • A: Not from base Fedora, but packages in some outer ring yes.
  • Q: Does one software collection means 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 character 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 playground is enough?

Questions with a proposed answer

  • Q: Where to keep sources of the collections
  • A: it will 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 RHSCL 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 does 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]