On 17/05/2021 14:32, Troy Dawson wrote: > > > On Mon, May 17, 2021 at 6:22 AM Fabian Arrotin <arrfab at centos.org > <mailto:arrfab at centos.org>> wrote: > > On 17/05/2021 15:10, Troy Dawson wrote: > > > > > > On Sat, May 15, 2021 at 6:47 AM Leon Fauster via CentOS-devel > > <centos-devel at centos.org <mailto:centos-devel at centos.org> > <mailto:centos-devel at centos.org <mailto:centos-devel at centos.org>>> > wrote: > > > > On 15.05.21 06:51, Troy Dawson wrote: > > > Back when the CentOS 8 Devel repo[1] was originally > introduced, the > > > CentOS Stream 8 Devel repo[2] was kept empty. > > > Now that CentOS 8 is going away, and we are expected to > develop on > > > CentOS Stream 8, could we please get CentOS Stream 8 Devel > populated > > > with the same packages it once had. > > > > > > I know there is an initiative for all the missing -devel > packages to > > > appear somewhere at sometime. But here is my problem. > > > I'm trying to get KDE rebuilt for CentOS Stream 8 due to the > > updated qt5 > > > that is now in Stream. > > > plasma-nm, a fairly important piece of KDE, requires > > > mobile-broadband-provider-info-devel which is in the Devel > repo. > > > From what I see, the fastest way to get > > > mobile-broadband-provider-info-devel somewhere that I can > consume > > it on > > > Stream is via the Devel repo. > > > Thus my question. > > > > > > Can we get CentOS Stream 8 Devel populated with whatever is > in the > > > regular Devel repo. > > > > > > Thanks > > > Troy Dawson > > > > > > [1] - > http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/ > <http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/> > > <http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/ > <http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/>> > > > > <http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/ > <http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/> > > <http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/ > <http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/>>> > > > [2] - > > > http://mirror.centos.org/centos/8-stream/Devel/x86_64/os/Packages/ > <http://mirror.centos.org/centos/8-stream/Devel/x86_64/os/Packages/> > > > <http://mirror.centos.org/centos/8-stream/Devel/x86_64/os/Packages/ <http://mirror.centos.org/centos/8-stream/Devel/x86_64/os/Packages/>> > > > > > > <http://mirror.centos.org/centos/8-stream/Devel/x86_64/os/Packages/ <http://mirror.centos.org/centos/8-stream/Devel/x86_64/os/Packages/> > > > <http://mirror.centos.org/centos/8-stream/Devel/x86_64/os/Packages/ <http://mirror.centos.org/centos/8-stream/Devel/x86_64/os/Packages/>>> > > > > > > > JFI: > > > > Downloads from koji instance allowed now. > > https://koji.mbox.centos.org/pkgs/packages/ > <https://koji.mbox.centos.org/pkgs/packages/> > > <https://koji.mbox.centos.org/pkgs/packages/ > <https://koji.mbox.centos.org/pkgs/packages/>> > > > > > > True, but that doesn't get them into the EPEL or COPR build > environment. > > > > Troy > > > > Hi Troy, > > As you're now part of the CentOS Stream team, when can we expect to see > that Devel repo being populated ? that would help for now SIGs building > in cbs.centos.org <http://cbs.centos.org> (and we have also again > other requests for built but > unreleased pkgs in Devel repo, so having a status update on that one > would be good too) > > > Well played good sir. > Unfortunately I only deal with the CentOS Stream 9 stuff, but I will > bring it up in the team meeting. > > I wrote this email on the centos-devel mailing list, as an EPEL package > maintainer, that has a problem. Because my EPEL work is done in my > spare time, and it's a legitimate EPEL packager problem. And I'd like > the solution to be public, and not behind closed doors. > > Troy > I'm not sure I understand why this is even an issue anymore. Now CentOS Stream is upstream of RHEL, surely there are no constraints to only ship what RHEL (downstream) ships? Why wouldn't CentOS Stream simply ship everything and if RHEL decides upon a policy to only ship/support a certain subset of (-devel) packages, that is a RH/RHEL decision that can be implemented downstream by removing the bits they don't want to ship/support and should have zero impact upstream? RH/RHEL are free to do whatever they want downstream. Or have I completely misunderstood the relationship here?