Hello,
I recently packaged a utility in Fedora 34[1] that enterprise cloud users might find helpful so I'd like to package it for CentOS 8 Stream and CentOS 9 Stream as well.
I've been following the CentOS Stream Contributing wiki page[2] to figure out how to get started with this. However, it seems like all of these instructions are only relevant if the package that someone would want to contribute to already has its own repo in the dist-git.
I've made some good progress on the CentOS 8 Stream package already, and I'm used to the Fedora process where this is about the time that I'd post it for review soon as part of the authorization process for getting a new repo in the dist-git.
Is there a CentOS equivalent to the Fedora package review process for getting a repo created?
Thank you,
Connor
[1] https://src.fedoraproject.org/rpms/rust-sevctl [2] https://wiki.centos.org/Contribute/CentOSStream
On Thu, Apr 15, 2021 at 10:30 AM Connor Kuehl ckuehl@redhat.com wrote:
Hello,
I recently packaged a utility in Fedora 34[1] that enterprise cloud users might find helpful so I'd like to package it for CentOS 8 Stream and CentOS 9 Stream as well.
I've been following the CentOS Stream Contributing wiki page[2] to figure out how to get started with this. However, it seems like all of these instructions are only relevant if the package that someone would want to contribute to already has its own repo in the dist-git.
That's correct.
I've made some good progress on the CentOS 8 Stream package already, and I'm used to the Fedora process where this is about the time that I'd post it for review soon as part of the authorization process for getting a new repo in the dist-git.
Is there a CentOS equivalent to the Fedora package review process for getting a repo created?
CentOS Stream is for content going into RHEL, so repos are added when a package is being added to RHEL. I'll send you some links to internal documentation on that.
If the package isn't going to be part of RHEL, you might look at adding it to EPEL instead.
josh
On Thu, Apr 15, 2021 at 11:50:37AM -0400, Josh Boyer wrote:
I recently packaged a utility in Fedora 34[1] that enterprise cloud users might find helpful so I'd like to package it for CentOS 8 Stream and CentOS 9 Stream as well.
[...]
If the package isn't going to be part of RHEL, you might look at adding it to EPEL instead.
Good news is that this is easy, especially since you already have packaged this in Fedora Linux. See https://fedoraproject.org/wiki/EPEL_Package_Maintainers (quick start: `fedpkg request-branch epel8`).
There isn't a 9 yet, but planning is underway.
On Thu, Apr 15, 2021 at 11:51 AM Josh Boyer jwboyer@redhat.com wrote:
CentOS Stream is for content going into RHEL, so repos are added when a package is being added to RHEL. I'll send you some links to internal documentation on that.
If the package isn't going to be part of RHEL, you might look at adding it to EPEL instead.
Is that really the whole story?
Yes, parts of Ceph and GlusterFS will be in 9. I've been operating on the premise though that the SIG packages that are landing in 8stream and 9stream are for people who are using 8stream or 9stream and want to try them out ahead of time. Have I misunderstood?
And BTW, AIUI, I'm not allowed to package them in EPEL.
--
Kaleb
On Thu, Apr 15, 2021 at 01:00:40PM -0400, Kaleb Keithley wrote:
Yes, parts of Ceph and GlusterFS will be in 9. I've been operating on the premise though that the SIG packages that are landing in 8stream and 9stream are for people who are using 8stream or 9stream and want to try them out ahead of time. Have I misunderstood?
And BTW, AIUI, I'm not allowed to package them in EPEL.
Is that because they overlap with RHEL packages? It should still be acceptable to package them as a module in EPEL.
On Thu, Apr 15, 2021 at 1:04 PM Matthew Miller mattdm@mattdm.org wrote:
On Thu, Apr 15, 2021 at 01:00:40PM -0400, Kaleb Keithley wrote:
Yes, parts of Ceph and GlusterFS will be in 9. I've been operating on
the
premise though that the SIG packages that are landing in 8stream and 9stream are for people who are using 8stream or 9stream and want to try them out ahead of time. Have I misunderstood?
And BTW, AIUI, I'm not allowed to package them in EPEL.
Is that because they overlap with RHEL packages? It should still be acceptable to package them as a module in EPEL.
Yes, they overlap with a) layered products (RHGS, RHCS) that Red Hat ships _on_ RHEL, and b) subsets of those layered products that ship _in_ RHEL; i.e. selected Ceph libraries and GlusterFS client-side packages.
And I haven't even scratched the surface of modules in Fedora or EPEL. Stephen Gallegher and I had some conversations a couple years ago when Fedora modules were new about making GlusterFS modules, but the need then for modules was unclear, and I've never looked any further into that.
--
Kaleb
On Thu, Apr 15, 2021 at 01:23:01PM -0400, Kaleb Keithley wrote:
And I haven't even scratched the surface of modules in Fedora or EPEL. Stephen Gallegher and I had some conversations a couple years ago when Fedora modules were new about making GlusterFS modules, but the need then for modules was unclear, and I've never looked any further into that.
The basic idea here is that you could make a non-default module stream, which when not enabled would never be installed from but when enabled, could replace "normal" packages. And modularity lets you define the set of such packages cleanly.
On Thu, Apr 15, 2021 at 1:23 PM Kaleb Keithley kkeithle@redhat.com wrote:
On Thu, Apr 15, 2021 at 1:04 PM Matthew Miller mattdm@mattdm.org wrote:
On Thu, Apr 15, 2021 at 01:00:40PM -0400, Kaleb Keithley wrote:
Yes, parts of Ceph and GlusterFS will be in 9. I've been operating on the premise though that the SIG packages that are landing in 8stream and 9stream are for people who are using 8stream or 9stream and want to try them out ahead of time. Have I misunderstood?
And BTW, AIUI, I'm not allowed to package them in EPEL.
Is that because they overlap with RHEL packages? It should still be acceptable to package them as a module in EPEL.
Yes, they overlap with a) layered products (RHGS, RHCS) that Red Hat ships _on_ RHEL, and b) subsets of those layered products that ship _in_ RHEL; i.e. selected Ceph libraries and GlusterFS client-side packages.
And I haven't even scratched the surface of modules in Fedora or EPEL. Stephen Gallegher and I had some conversations a couple years ago when Fedora modules were new about making GlusterFS modules, but the need then for modules was unclear, and I've never looked any further into that.
Modules are like Richard Stallman. Unkempt, difficult to tolerate, and unwelcome on many campuses, even if the philosphy sounds very appealing at first glance and it's not being deliberately offensive. (And yes, I've known rms since the 1980's.)
On 4/15/21 10:30 PM, Nico Kadel-Garcia wrote:
On Thu, Apr 15, 2021 at 1:23 PM Kaleb Keithley kkeithle@redhat.com wrote:
On Thu, Apr 15, 2021 at 1:04 PM Matthew Miller mattdm@mattdm.org wrote:
On Thu, Apr 15, 2021 at 01:00:40PM -0400, Kaleb Keithley wrote:
Yes, parts of Ceph and GlusterFS will be in 9. I've been operating on the premise though that the SIG packages that are landing in 8stream and 9stream are for people who are using 8stream or 9stream and want to try them out ahead of time. Have I misunderstood?
And BTW, AIUI, I'm not allowed to package them in EPEL.
Is that because they overlap with RHEL packages? It should still be acceptable to package them as a module in EPEL.
Yes, they overlap with a) layered products (RHGS, RHCS) that Red Hat ships _on_ RHEL, and b) subsets of those layered products that ship _in_ RHEL; i.e. selected Ceph libraries and GlusterFS client-side packages.
And I haven't even scratched the surface of modules in Fedora or EPEL. Stephen Gallegher and I had some conversations a couple years ago when Fedora modules were new about making GlusterFS modules, but the need then for modules was unclear, and I've never looked any further into that.
Modules are like Richard Stallman. Unkempt, difficult to tolerate, and unwelcome on many campuses, even if the philosphy sounds very appealing at first glance and it's not being deliberately offensive. (And yes, I've known rms since the 1980's.)
No argument from me on that. But, it is something that we have to use now. May as well use it as intended.
On Thu, Apr 15, 2021 at 1:01 PM Kaleb Keithley kkeithle@redhat.com wrote:
On Thu, Apr 15, 2021 at 11:51 AM Josh Boyer jwboyer@redhat.com wrote:
CentOS Stream is for content going into RHEL, so repos are added when a package is being added to RHEL. I'll send you some links to internal documentation on that.
If the package isn't going to be part of RHEL, you might look at adding it to EPEL instead.
Is that really the whole story?
For a single package that is not part of RHEL, it's possibly the best story. But there are other stories, like SIGs.
Yes, parts of Ceph and GlusterFS will be in 9. I've been operating on the premise though that the SIG packages that are landing in 8stream and 9stream are for people who are using 8stream or 9stream and want to try them out ahead of time. Have I misunderstood?
Can you point to where a SIG build has landed directly in Stream? I don't think you've misunderstood as much as we might be using different terminology. Let's clarify:
Stream packages == content that will land in a future RHEL release Stream SIG packages == content that builds *on top of* CentOS Stream, but does not directly land in Stream (neither the buildroot or the composes).
There may certainly be cases where a SIG does work and then we include that work at a future date into Stream (and therefore RHEL). However, that needs to be coordinated up front.
josh
On Fri, Apr 16, 2021 at 10:39 AM Josh Boyer jwboyer@redhat.com wrote:
On Thu, Apr 15, 2021 at 1:01 PM Kaleb Keithley kkeithle@redhat.com wrote:
On Thu, Apr 15, 2021 at 11:51 AM Josh Boyer jwboyer@redhat.com wrote:
Can you point to where a SIG build has landed directly in Stream?
The only SIG I really know anything about is Storage, and so far nothing from Storage is ready for c8stream.
I've just finished building Ceph, Gluster, and NFS-Ganesha for c8stream and was getting ready to pull the trigger to have hughesjr build the Centos-Release-{Ceph,Gluster,NFS-Ganesha} packages for c8stream when this came across my radar.
I don't think you've misunderstood as much as we might be using different terminology. Let's clarify:
Stream packages == content that will land in a future RHEL release Stream SIG packages == content that builds *on top of* CentOS Stream, but does not directly land in Stream (neither the buildroot or the composes).
I was expecting that the packages I've just built would fall into the latter category.
There may certainly be cases where a SIG does work and then we include that work at a future date into Stream (and therefore RHEL). However, that needs to be coordinated up front.
I'm not expecting the SIG Storage packages to ever land _in_ Stream (buildroot or composes) or RHEL. Those Ceph and Gluster bits that I mentioned previously are being handled separately, elsewhere, by other people, and I'm not familiar with the mechanics of making that happen.
HTH,
--
Kaleb
On Fri, Apr 16, 2021 at 11:29 AM Kaleb Keithley kkeithle@redhat.com wrote:
On Fri, Apr 16, 2021 at 10:39 AM Josh Boyer jwboyer@redhat.com wrote:
On Thu, Apr 15, 2021 at 1:01 PM Kaleb Keithley kkeithle@redhat.com wrote:
On Thu, Apr 15, 2021 at 11:51 AM Josh Boyer jwboyer@redhat.com wrote:
Can you point to where a SIG build has landed directly in Stream?
The only SIG I really know anything about is Storage, and so far nothing from Storage is ready for c8stream.
I've just finished building Ceph, Gluster, and NFS-Ganesha for c8stream and was getting ready to pull the trigger to have hughesjr build the Centos-Release-{Ceph,Gluster,NFS-Ganesha} packages for c8stream when this came across my radar.
I don't think you've misunderstood as much as we might be using different terminology. Let's clarify:
Stream packages == content that will land in a future RHEL release Stream SIG packages == content that builds *on top of* CentOS Stream, but does not directly land in Stream (neither the buildroot or the composes).
I was expecting that the packages I've just built would fall into the latter category.
There may certainly be cases where a SIG does work and then we include that work at a future date into Stream (and therefore RHEL). However, that needs to be coordinated up front.
I'm not expecting the SIG Storage packages to ever land _in_ Stream (buildroot or composes) or RHEL. Those Ceph and Gluster bits that I mentioned previously are being handled separately, elsewhere, by other people, and I'm not familiar with the mechanics of making that happen.
Sounds like you understand it well then!
josh
-
Connor Kuehl -
Johnny Hughes -
Josh Boyer -
Kaleb Keithley -
Matthew Miller -
Nico Kadel-Garcia