From Fedora Project Wiki
 
(2 intermediate revisions by the same user not shown)
Line 10: Line 10:
=== Open questions ===
=== 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: 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: 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: What distinguishes rings and/or what is "main" fedora? build system? level of support? level of stability/assurance? All together?
Line 30: Line 30:
* A: To specify guidelines/rules/best practices to build, deliver and use Software Collections in 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) ==
== 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.
Basic usage after installing is pretty much defined by ''scl-utils'' usage. The bigger issue is with working with repositories.
Line 36: Line 36:
=== Questions with a proposed answer ===  
=== Questions with a proposed answer ===  


* Q: How packagers and relengs will work with the collections:
* Q: How packagers and rel-eng will work with the collections:
* A: Partial answer at [[https://fedoraproject.org/wiki/User:Mmaslano/SCL Use cases for packager and 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 building of non-scl packages on top of SCL?
* A: Not from 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 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.
* 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.


Line 49: Line 49:
=== Open questions ===
=== 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: 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: 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?
* Q: how to handle updates? do we want something like bodhi for collections? Or is playground is enough?


=== Questions with a proposed answer ===  
=== Questions with a proposed answer ===  


* Q: Where to keep sources of the collections
* Q: Where to keep the sources for a 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.  
* 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?
* Q: Build system?
* A: Copr with signing?
* A: Copr with signing?


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


* Q: what collections names to use?
* 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.
* 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?
* 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.
* 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?
* Q: Reviews of the RPM specs and collections generally?
Line 86: Line 86:
* A: we may need to adjust/define buildroot where these repositories will be installed (does it work in mock?)
* 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?
* 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.
* 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.



Latest revision as of 13:02, 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 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: 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]