(Of course, we should be asking RH... but nevertheless)
EPEL 8 has several issues regarding packages without corresponding -devel. E.g., libXvMC, libbluray. I see that this causes grief for EPEL 8 and collateral damage to RPMFusion.
Did RH disclose the reason for this? Was there any discussion on where CentOS will put them, like in Extras perhaps?
(I was rolling out some testing VMs in RHEL8 and OL8, and noticed the new but "unsupported" CodeReady repos with -devel packages; yet not all -devels are them.)
Cheers Anthony
* On 8/25/19 6:04 AM, Anthony Alba wrote:
(Of course, we should be asking RH... but nevertheless)
EPEL 8 has several issues regarding packages without corresponding -devel. E.g., libXvMC, libbluray. I see that this causes grief for EPEL 8 and collateral damage to RPMFusion.
EPEL 8 does not have such a problem. EPEL 8 doesn't even include libbluray or libXvMC (at the current point in time).
EPEL is a Fedora-maintained project supplying additional packages. It's maintained by other people than CentOS.
Did RH disclose the reason for this? Was there any discussion on where CentOS will put them, like in Extras perhaps?
(I was rolling out some testing VMs in RHEL8 and OL8, and noticed the new but "unsupported" CodeReady repos with -devel packages; yet not all -devels are them.)
Right, the problem is isolated to RHEL 8. You're probably stumbling on some of the rough edges of their release. Also note that there is no official CentOS 8 repository yet, so don't assume CentOS 8 will have the problem once it's released.
I have no Red Hat subscription so can't tell you what RH's repositories look like. I did find source RPMs for the RHEL 8 beta, though, and looked into it. The libbluray source package in there does define a -devel sub package, so it's probably also generated at build time.
No idea where they, if they even do, publish it.
To be fair, RHEL not providing the -devel sub packages is not an immediate concern or problem for the CentOS project, since the latter is rebuilding source RPMs they get from RH(EL).
For libbluray, it's easy to see that a -devel package is generated and published: https://koji.mbox.centos.org/koji/buildinfo?buildID=1084
No need to worry.
As to why RH doesn't publish the packages... you really very much will have to ask them.
Mihai
On Sun, Aug 25, 2019 at 12:05 AM Anthony Alba ascanio.alba7@gmail.com wrote:
(Of course, we should be asking RH... but nevertheless)
EPEL 8 has several issues regarding packages without corresponding -devel. E.g., libXvMC, libbluray.
AIUI, certain -devel packages land in the CodeReady repo. But these two in particular are not actually in the CodeReady repo.
It appears it was not an oversight. See https://bugzilla.redhat.com/show_bug.cgi?id=1713421. (Some comments are private.)
And FWIW, you can always get the src RPMs and build them yourself to get the -devel packages. Generally I'd agree that you should not have to do this, but based on the private comments in that BZ I'd guess that that may be your only option at this time.
HTH
--
Kaleb
On Sun, Aug 25, 2019 at 8:19 AM Kaleb Keithley kkeithle@redhat.com wrote:
On Sun, Aug 25, 2019 at 12:05 AM Anthony Alba ascanio.alba7@gmail.com wrote:
(Of course, we should be asking RH... but nevertheless)
EPEL 8 has several issues regarding packages without corresponding -devel. E.g., libXvMC, libbluray.
AIUI, certain -devel packages land in the CodeReady repo. But these two in particular are not actually in the CodeReady repo.
It appears it was not an oversight. See https://bugzilla.redhat.com/show_bug.cgi?id=1713421. (Some comments are private.)
And FWIW, you can always get the src RPMs and build them yourself to get the -devel packages. Generally I'd agree that you should not have to do this, but based on the private comments in that BZ I'd guess that that may be your only option at this time.
That whole bug report is private. I can't read it, nor do I imagine anyone else can.
I hope that CentOS 8 won't follow RHEL 8 in this manner, and we'll have all the -devel subpackages available and integrated into the repos or something. Otherwise, it's going to be extremely painful to build on top without rebuilding things to get access to components that were already built...
-- 真実はいつも一つ！/ Always, there's only one truth!
On Tue, Aug 27, 2019 at 10:02 PM Neal Gompa ngompa13@gmail.com wrote:
On Sun, Aug 25, 2019 at 8:19 AM Kaleb Keithley kkeithle@redhat.com wrote:
On Sun, Aug 25, 2019 at 12:05 AM Anthony Alba ascanio.alba7@gmail.com wrote:
(Of course, we should be asking RH... but nevertheless)
EPEL 8 has several issues regarding packages without corresponding -devel. E.g., libXvMC, libbluray.
AIUI, certain -devel packages land in the CodeReady repo. But these two in particular are not actually in the CodeReady repo.
It appears it was not an oversight. See https://bugzilla.redhat.com/show_bug.cgi?id=1713421. (Some comments are private.)
And FWIW, you can always get the src RPMs and build them yourself to get the -devel packages. Generally I'd agree that you should not have to do this, but based on the private comments in that BZ I'd guess that that may be your only option at this time.
That whole bug report is private. I can't read it, nor do I imagine anyone else can.
I hope that CentOS 8 won't follow RHEL 8 in this manner, and we'll have all the -devel subpackages available and integrated into the repos or something. Otherwise, it's going to be extremely painful to build on top without rebuilding things to get access to components that were already built...
I can't read that bug report, and I have a personal Red Hat account with my RHEL 8 license. What is the point of bug report not even your customers can read?
The latest release of "mock" and "mock-core-configs" from the git repos work reasonably well with RHEL 8. I've published RPM wrappers for them, at https://github.com/nkadel/mockrepo . Getting the RHEL 8 keys means declaring a subscription key manually right now.
Le 01/09/2019 à 04:41, Nico Kadel-Garcia a écrit :
On Tue, Aug 27, 2019 at 10:02 PM Neal Gompa ngompa13@gmail.com wrote:
On Sun, Aug 25, 2019 at 8:19 AM Kaleb Keithley kkeithle@redhat.com wrote:
On Sun, Aug 25, 2019 at 12:05 AM Anthony Alba ascanio.alba7@gmail.com wrote:
(Of course, we should be asking RH... but nevertheless)
EPEL 8 has several issues regarding packages without corresponding -devel. E.g., libXvMC, libbluray.
AIUI, certain -devel packages land in the CodeReady repo. But these two in particular are not actually in the CodeReady repo.
It appears it was not an oversight. See https://bugzilla.redhat.com/show_bug.cgi?id=1713421. (Some comments are private.)
And FWIW, you can always get the src RPMs and build them yourself to get the -devel packages. Generally I'd agree that you should not have to do this, but based on the private comments in that BZ I'd guess that that may be your only option at this time.
That whole bug report is private. I can't read it, nor do I imagine anyone else can.
I hope that CentOS 8 won't follow RHEL 8 in this manner, and we'll have all the -devel subpackages available and integrated into the repos or something. Otherwise, it's going to be extremely painful to build on top without rebuilding things to get access to components that were already built...
I can't read that bug report, and I have a personal Red Hat account with my RHEL 8 license. What is the point of bug report not even your customers can read?
I'd be genuinely interested if anyone with access to this bug can give a quick summary of the reasons.
From the point of view of people building additional stuff that is needed to get RHEL/CentOS more useful, be it EPEL or RPM Fusion and probably others, the missing -devel are just another pain point on top of the already painful modular repos, I can't believe Red Hat did that gratuitously...
Regards, Xavier
On Tue, Sep 3, 2019 at 4:57 AM Xavier Bachelot xavier@bachelot.org wrote:
Le 01/09/2019 à 04:41, Nico Kadel-Garcia a écrit :
On Tue, Aug 27, 2019 at 10:02 PM Neal Gompa ngompa13@gmail.com wrote:
On Sun, Aug 25, 2019 at 8:19 AM Kaleb Keithley kkeithle@redhat.com wrote:
On Sun, Aug 25, 2019 at 12:05 AM Anthony Alba ascanio.alba7@gmail.com wrote:
(Of course, we should be asking RH... but nevertheless)
EPEL 8 has several issues regarding packages without corresponding -devel. E.g., libXvMC, libbluray.
AIUI, certain -devel packages land in the CodeReady repo. But these two in particular are not actually in the CodeReady repo.
It appears it was not an oversight. See https://bugzilla.redhat.com/show_bug.cgi?id=1713421. (Some comments are private.)
And FWIW, you can always get the src RPMs and build them yourself to get the -devel packages. Generally I'd agree that you should not have to do this, but based on the private comments in that BZ I'd guess that that may be your only option at this time.
That whole bug report is private. I can't read it, nor do I imagine anyone else can.
I hope that CentOS 8 won't follow RHEL 8 in this manner, and we'll have all the -devel subpackages available and integrated into the repos or something. Otherwise, it's going to be extremely painful to build on top without rebuilding things to get access to components that were already built...
I can't read that bug report, and I have a personal Red Hat account with my RHEL 8 license. What is the point of bug report not even your customers can read?
I'd be genuinely interested if anyone with access to this bug can give a quick summary of the reasons.
From the point of view of people building additional stuff that is needed to get RHEL/CentOS more useful, be it EPEL or RPM Fusion and probably others, the missing -devel are just another pain point on top of the already painful modular repos, I can't believe Red Hat did that gratuitously...
In my experience with RHEL, it has made my work ridiculously harder. Whatever reason Red Hat had for this, it definitely was not worth making it so difficult for people to develop software for RHEL...
Caleb, can you quote or paraphrase the subscription-only bug report? I can’t see its contents, even with my subscription, and would appreciate any detail you can legally pass along.
Sent from my iPhone
On Tue, Sep 3, 2019 at 4:57 AM Xavier Bachelot xavier@bachelot.org wrote:
I'd be genuinely interested if anyone with access to this bug can give a quick summary of the reasons.
It boils down to only gvfs uses it. And it only uses it to read the title and the thumbnail from discs.
Opening the library for general consumption by publishing the -devel rpm opens Red Hat to other risks, e.g. dealing with CVEs in other parts of the library that Red Hat doesn't use.
(It seems to me they could have quite simply given the library a different name and avoided the whole issue.)
It looks like the people responsible for it will try to remove libbluray from RHEL8, opening the door for EPEL, one of the CentOS SIGs, or others to publish whatever they want without creating a conflict with the one in RHEL.
N.B. that's only libbluray. libXvMC is another matter.
--
Kaleb
Le 03/09/2019 à 14:41, Kaleb Keithley a écrit :
On Tue, Sep 3, 2019 at 4:57 AM Xavier Bachelot <xavier@bachelot.org mailto:xavier@bachelot.org> wrote:
I'd be genuinely interested if anyone with access to this bug can give a quick summary of the reasons.It boils down to only gvfs uses it. And it only uses it to read the title and the thumbnail from discs.
Opening the library for general consumption by publishing the -devel rpm opens Red Hat to other risks, e.g. dealing with CVEs in other parts of the library that Red Hat doesn't use.
(It seems to me they could have quite simply given the library a different name and avoided the whole issue.)
It looks like the people responsible for it will try to remove libbluray from RHEL8, opening the door for EPEL, one of the CentOS SIGs, or others to publish whatever they want without creating a conflict with the one in RHEL.
N.B. that's only libbluray. libXvMC is another matter.
Fine by me, I'm the original packager and Fedora maintainer for libbluray. Give it back to me, it'll get more love from me in EPEL than what it gets from Red Hat in RHEL :-)
Meanwhile, not publishing the -devel won't prevent people from using it, it will just make it harder to get potential issues fixed because the RHEL SRPM is what will be used to recreate the missing -devel and there will be no way to get Red Hat to fix the bugs in the part of the lib they don't care about.
Now, what about libXvMC and all the others ? There must be some reasons too. Imho, CBR is a weird idea, not publishing all -devel is even weirder. With the assumption and strong hope that CentOS won't replicate this dubious trick of segregating (part of) the -devel in a separate repo, it definitely looks like a saner platform to me.
Thanks for sharing Kaleb, much appreciated.
Regards, Xavier
Am 03.09.19 um 10:57 schrieb Xavier Bachelot:
Le 01/09/2019 à 04:41, Nico Kadel-Garcia a écrit :
On Tue, Aug 27, 2019 at 10:02 PM Neal Gompa ngompa13@gmail.com wrote:
On Sun, Aug 25, 2019 at 8:19 AM Kaleb Keithley kkeithle@redhat.com wrote:
On Sun, Aug 25, 2019 at 12:05 AM Anthony Alba ascanio.alba7@gmail.com wrote:
(Of course, we should be asking RH... but nevertheless)
EPEL 8 has several issues regarding packages without corresponding -devel. E.g., libXvMC, libbluray.
AIUI, certain -devel packages land in the CodeReady repo. But these two in particular are not actually in the CodeReady repo.
It appears it was not an oversight. See https://bugzilla.redhat.com/show_bug.cgi?id=1713421. (Some comments are private.)
And FWIW, you can always get the src RPMs and build them yourself to get the -devel packages. Generally I'd agree that you should not have to do this, but based on the private comments in that BZ I'd guess that that may be your only option at this time.
That whole bug report is private. I can't read it, nor do I imagine anyone else can.
I hope that CentOS 8 won't follow RHEL 8 in this manner, and we'll have all the -devel subpackages available and integrated into the repos or something. Otherwise, it's going to be extremely painful to build on top without rebuilding things to get access to components that were already built...
I can't read that bug report, and I have a personal Red Hat account with my RHEL 8 license. What is the point of bug report not even your customers can read?
I'd be genuinely interested if anyone with access to this bug can give a quick summary of the reasons.
The bug report was open by me and communicates the missing libbluray-devel package. Its closed now with "WONTFIX" ...
I did the same for libXvMC-devel and its assigned now. High probability that it will land in the CRB repo (maybe EL8.1).
-- Leon
I'm still building from an updated OSTree, to build ISOs.
CoreOS is still bleeding hemorrhaging junk with no roadmap.
Are Centos Atomic builders forever stuck with jbrooks' secret git proj? (After having to hack lorax on centos 7?)
On 18/10/2019 12:53, Dan Seguin wrote:
I'm still building from an updated OSTree, to build ISOs.
CoreOS is still bleeding hemorrhaging junk with no roadmap.
Are Centos Atomic builders forever stuck with jbrooks' secret git proj? (After having to hack lorax on centos 7?)
Jason and I were talking about this recently, the plan was to keep Atomic going as far as we can, and see how the CoreOS ecosystem shapes up in the mean time.
regards
Thx for the response.
I'd love to help where I can.
________________________________________ From: CentOS-devel centos-devel-bounces@centos.org on behalf of Karanbir Singh kbsingh@centos.org Sent: October 18, 2019 9:04 AM To: centos-devel@centos.org Subject: Re: [CentOS-devel] Centos Atomic deprecated?
On 18/10/2019 12:53, Dan Seguin wrote:
I'm still building from an updated OSTree, to build ISOs.
CoreOS is still bleeding hemorrhaging junk with no roadmap.
Are Centos Atomic builders forever stuck with jbrooks' secret git proj? (After having to hack lorax on centos 7?)
Jason and I were talking about this recently, the plan was to keep Atomic going as far as we can, and see how the CoreOS ecosystem shapes up in the mean time.
regards
_______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Any update on this?
IRC is cold.
________________________________________ From: CentOS-devel centos-devel-bounces@centos.org on behalf of Karanbir Singh kbsingh@centos.org Sent: October 18, 2019 9:04 AM To: centos-devel@centos.org Subject: Re: [CentOS-devel] Centos Atomic deprecated?
On 18/10/2019 12:53, Dan Seguin wrote:
I'm still building from an updated OSTree, to build ISOs.
CoreOS is still bleeding hemorrhaging junk with no roadmap.
Are Centos Atomic builders forever stuck with jbrooks' secret git proj? (After having to hack lorax on centos 7?)
Jason and I were talking about this recently, the plan was to keep Atomic going as far as we can, and see how the CoreOS ecosystem shapes up in the mean time.
regards
_______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Tue, Nov 19, 2019 at 2:23 AM Dan Seguin dan.seguin@cord3inc.com wrote:
Any update on this?
Sorry for the delay, the bits are in place now.
Jason
IRC is cold.
From: CentOS-devel centos-devel-bounces@centos.org on behalf of Karanbir Singh kbsingh@centos.org Sent: October 18, 2019 9:04 AM To: centos-devel@centos.org Subject: Re: [CentOS-devel] Centos Atomic deprecated?
On 18/10/2019 12:53, Dan Seguin wrote:
I'm still building from an updated OSTree, to build ISOs.
CoreOS is still bleeding hemorrhaging junk with no roadmap.
Are Centos Atomic builders forever stuck with jbrooks' secret git proj? (After having to hack lorax on centos 7?)
Jason and I were talking about this recently, the plan was to keep Atomic going as far as we can, and see how the CoreOS ecosystem shapes up in the mean time.
regards
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Super!
thx.
________________________________________ From: CentOS-devel centos-devel-bounces@centos.org on behalf of Jason Brooks jbrooks@redhat.com Sent: November 21, 2019 5:36 PM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] Centos Atomic deprecated?
On Tue, Nov 19, 2019 at 2:23 AM Dan Seguin dan.seguin@cord3inc.com wrote:
Any update on this?
Sorry for the delay, the bits are in place now.
Jason
IRC is cold.
From: CentOS-devel centos-devel-bounces@centos.org on behalf of Karanbir Singh kbsingh@centos.org Sent: October 18, 2019 9:04 AM To: centos-devel@centos.org Subject: Re: [CentOS-devel] Centos Atomic deprecated?
On 18/10/2019 12:53, Dan Seguin wrote:
I'm still building from an updated OSTree, to build ISOs.
CoreOS is still bleeding hemorrhaging junk with no roadmap.
Are Centos Atomic builders forever stuck with jbrooks' secret git proj? (After having to hack lorax on centos 7?)
Jason and I were talking about this recently, the plan was to keep Atomic going as far as we can, and see how the CoreOS ecosystem shapes up in the mean time.
regards
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-- Jason Brooks Community Architects & Infrastructure Red Hat Open Source Program Office (OSPO) https://community.redhat.com | https://osci.io
_______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Hello all,
These are great news!
I would like to ask about centos8 atomic.
Will it happen? I could help where I can.
Cheers, Spyros
On Fri, Nov 22, 2019, 8:12 PM Dan Seguin dan.seguin@cord3inc.com wrote:
Super!
thx.
From: CentOS-devel centos-devel-bounces@centos.org on behalf of Jason Brooks jbrooks@redhat.com Sent: November 21, 2019 5:36 PM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] Centos Atomic deprecated?
On Tue, Nov 19, 2019 at 2:23 AM Dan Seguin dan.seguin@cord3inc.com wrote:
Any update on this?
Sorry for the delay, the bits are in place now.
Jason
IRC is cold.
From: CentOS-devel centos-devel-bounces@centos.org on behalf of
Karanbir Singh kbsingh@centos.org
Sent: October 18, 2019 9:04 AM To: centos-devel@centos.org Subject: Re: [CentOS-devel] Centos Atomic deprecated?
On 18/10/2019 12:53, Dan Seguin wrote:
I'm still building from an updated OSTree, to build ISOs.
CoreOS is still bleeding hemorrhaging junk with no roadmap.
Are Centos Atomic builders forever stuck with jbrooks' secret git
proj? (After having to hack lorax on centos 7?)
Jason and I were talking about this recently, the plan was to keep Atomic going as far as we can, and see how the CoreOS ecosystem shapes up in the mean time.
regards
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-- Jason Brooks Community Architects & Infrastructure Red Hat Open Source Program Office (OSPO) https://community.redhat.com | https://osci.io
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
I'll help on this too, if it includes all the bug fixes for the disastrous anaconda.
CoreOS looks like it's still a year out, Fedora compared to CentOS has never been a good bet.
I've been building CentOS Atomic from old OStrees, but with the old Lorax it's damn painful.
Could use some guidance and help.
________________________________ From: CentOS-devel centos-devel-bounces@centos.org on behalf of Spyros Trigazis strigazi@gmail.com Sent: November 22, 2019 3:09 PM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] Centos Atomic deprecated?
Hello all,
These are great news!
I would like to ask about centos8 atomic.
Will it happen? I could help where I can.
Cheers, Spyros
On Fri, Nov 22, 2019, 8:12 PM Dan Seguin <dan.seguin@cord3inc.commailto:dan.seguin@cord3inc.com> wrote: Super!
thx.
________________________________________ From: CentOS-devel <centos-devel-bounces@centos.orgmailto:centos-devel-bounces@centos.org> on behalf of Jason Brooks <jbrooks@redhat.commailto:jbrooks@redhat.com> Sent: November 21, 2019 5:36 PM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] Centos Atomic deprecated?
On Tue, Nov 19, 2019 at 2:23 AM Dan Seguin <dan.seguin@cord3inc.commailto:dan.seguin@cord3inc.com> wrote:
Any update on this?
Sorry for the delay, the bits are in place now.
Jason
IRC is cold.
From: CentOS-devel <centos-devel-bounces@centos.orgmailto:centos-devel-bounces@centos.org> on behalf of Karanbir Singh <kbsingh@centos.orgmailto:kbsingh@centos.org> Sent: October 18, 2019 9:04 AM To: centos-devel@centos.orgmailto:centos-devel@centos.org Subject: Re: [CentOS-devel] Centos Atomic deprecated?
On 18/10/2019 12:53, Dan Seguin wrote:
I'm still building from an updated OSTree, to build ISOs.
CoreOS is still bleeding hemorrhaging junk with no roadmap.
Are Centos Atomic builders forever stuck with jbrooks' secret git proj? (After having to hack lorax on centos 7?)
Jason and I were talking about this recently, the plan was to keep Atomic going as far as we can, and see how the CoreOS ecosystem shapes up in the mean time.
regards
CentOS-devel mailing list CentOS-devel@centos.orgmailto:CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.orgmailto:CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-- Jason Brooks Community Architects & Infrastructure Red Hat Open Source Program Office (OSPO) https://community.redhat.com | https://osci.io
_______________________________________________ CentOS-devel mailing list CentOS-devel@centos.orgmailto:CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.orgmailto:CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Fri, Nov 22, 2019 at 12:09 PM Spyros Trigazis strigazi@gmail.com wrote:
Hello all,
These are great news!
I would like to ask about centos8 atomic.
There's no current plan to do an 8-based atomic host. There's no RHEL 8 atomic host to follow, so it'd have to be a new thing.
Will it happen? I could help where I can.
Cheers, Spyros
On Fri, Nov 22, 2019, 8:12 PM Dan Seguin dan.seguin@cord3inc.com wrote:
Super!
thx.
From: CentOS-devel centos-devel-bounces@centos.org on behalf of Jason Brooks jbrooks@redhat.com Sent: November 21, 2019 5:36 PM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] Centos Atomic deprecated?
On Tue, Nov 19, 2019 at 2:23 AM Dan Seguin dan.seguin@cord3inc.com wrote:
Any update on this?
Sorry for the delay, the bits are in place now.
Jason
IRC is cold.
From: CentOS-devel centos-devel-bounces@centos.org on behalf of Karanbir Singh kbsingh@centos.org Sent: October 18, 2019 9:04 AM To: centos-devel@centos.org Subject: Re: [CentOS-devel] Centos Atomic deprecated?
On 18/10/2019 12:53, Dan Seguin wrote:
I'm still building from an updated OSTree, to build ISOs.
CoreOS is still bleeding hemorrhaging junk with no roadmap.
Are Centos Atomic builders forever stuck with jbrooks' secret git proj? (After having to hack lorax on centos 7?)
Jason and I were talking about this recently, the plan was to keep Atomic going as far as we can, and see how the CoreOS ecosystem shapes up in the mean time.
regards
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-- Jason Brooks Community Architects & Infrastructure Red Hat Open Source Program Office (OSPO) https://community.redhat.com | https://osci.io
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Hi Jason,
On 11/25/19 8:08 PM, Jason Brooks wrote:
On Fri, Nov 22, 2019 at 12:09 PM Spyros Trigazis strigazi@gmail.com wrote:
Hello all,
These are great news!
I would like to ask about centos8 atomic.
There's no current plan to do an 8-based atomic host. There's no RHEL 8 atomic host to follow, so it'd have to be a new thing.
So for the coreos / ostree tooling,Should we look at :
https://github.com/coreos/coreos-assembler
and how much effort it would be to use these tools on CentOS 8 and with C8 as a target ?
Is there relevant blog posts or other documentation we could look at ?
Disclaimer; I didn't google much it's just a new use-case I am investigating for atomic/coreos rather than centos install.
Whatever you or I find, I will share and help. As I mentioned before, Centos 7 ATomic has huge broken tooling for re-spins. Lorax is lacking for C7. *cough* anaconda updates *cough* And many Lorax changes...
Would *love* to move to Assembler as Jason told me so long ago....
Dan ________________________________________ From: CentOS-devel centos-devel-bounces@centos.org on behalf of Thomas Oulevey thomas.oulevey@cern.ch Sent: November 26, 2019 4:32 AM To: centos-devel@centos.org Subject: Re: [CentOS-devel] Centos Atomic deprecated?
Hi Jason,
On 11/25/19 8:08 PM, Jason Brooks wrote:
On Fri, Nov 22, 2019 at 12:09 PM Spyros Trigazis strigazi@gmail.com wrote:
Hello all,
These are great news!
I would like to ask about centos8 atomic.
There's no current plan to do an 8-based atomic host. There's no RHEL 8 atomic host to follow, so it'd have to be a new thing.
So for the coreos / ostree tooling,Should we look at :
https://github.com/coreos/coreos-assembler
and how much effort it would be to use these tools on CentOS 8 and with C8 as a target ?
Is there relevant blog posts or other documentation we could look at ?
Disclaimer; I didn't google much it's just a new use-case I am investigating for atomic/coreos rather than centos install.
-- Thomas 'alphacc' Oulevey _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Being part of CentOS PaaS SIG, and seeing OKD v4 taking shape, I offer my time to assist in moving towards coreos assembler, or to help in any other way the community proposes.
As soon as we have an equivalent of coreos on CentOS, we will be able to begin our work to release OKD v4. Therefore, this conversation is of our interest.
Probably we will need to form a SIG to investigate this, if one wasn’t already formed.
Thanks, Gleidson On 27 Nov 2019, 12:09 AM +1300, Dan Seguin dan.seguin@Cord3Inc.com, wrote: Whatever you or I find, I will share and help. As I mentioned before, Centos 7 ATomic has huge broken tooling for re-spins. Lorax is lacking for C7. *cough* anaconda updates *cough* And many Lorax changes...
Would *love* to move to Assembler as Jason told me so long ago....
Dan ________________________________________
On Tue, Nov 26, 2019 at 8:44 AM Gleidson Nascimento slaterx@live.com wrote:
Being part of CentOS PaaS SIG, and seeing OKD v4 taking shape, I offer my time to assist in moving towards coreos assembler, or to help in any other way the community proposes.
As soon as we have an equivalent of coreos on CentOS, we will be able to begin our work to release OKD v4. Therefore, this conversation is of our interest.
There's a preview release of OKD 4 out: https://github.com/openshift/okd/blob/master/README.md
They're using Fedora CoreOS for it.
Probably we will need to form a SIG to investigate this, if one wasn’t already formed.
Thanks, Gleidson On 27 Nov 2019, 12:09 AM +1300, Dan Seguin dan.seguin@Cord3Inc.com, wrote:
Whatever you or I find, I will share and help. As I mentioned before, Centos 7 ATomic has huge broken tooling for re-spins. Lorax is lacking for C7. *cough* anaconda updates *cough* And many Lorax changes...
Would *love* to move to Assembler as Jason told me so long ago....
Dan ________________________________________
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Thanks for that, but Kerbunetes is not desired, in fact, it is not wanted.
I'll save it for future reference.
Cheers. ________________________________________ From: CentOS-devel centos-devel-bounces@centos.org on behalf of Jason Brooks jbrooks@redhat.com Sent: November 26, 2019 12:24 PM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] Centos Atomic deprecated?
On Tue, Nov 26, 2019 at 8:44 AM Gleidson Nascimento slaterx@live.com wrote:
Being part of CentOS PaaS SIG, and seeing OKD v4 taking shape, I offer my time to assist in moving towards coreos assembler, or to help in any other way the community proposes.
As soon as we have an equivalent of coreos on CentOS, we will be able to begin our work to release OKD v4. Therefore, this conversation is of our interest.
There's a preview release of OKD 4 out: https://github.com/openshift/okd/blob/master/README.md
They're using Fedora CoreOS for it.
Probably we will need to form a SIG to investigate this, if one wasn’t already formed.
Thanks, Gleidson On 27 Nov 2019, 12:09 AM +1300, Dan Seguin dan.seguin@Cord3Inc.com, wrote:
Whatever you or I find, I will share and help. As I mentioned before, Centos 7 ATomic has huge broken tooling for re-spins. Lorax is lacking for C7. *cough* anaconda updates *cough* And many Lorax changes...
Would *love* to move to Assembler as Jason told me so long ago....
Dan ________________________________________
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-- Jason Brooks Community Architects & Infrastructure Red Hat Open Source Program Office (OSPO) https://community.redhat.com | https://osci.io
_______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Hello,
Centos will receive updates full updates up to Q4 2020 and maintenance up to 2024 [0]. What about Centos Atomic? Until when will we have builds?
IMO it would make more sense to build centos atomic 8 but as mentioned above this would be something new entirely.
Thanks, Spyros
[0] https://wiki.centos.org/About/Product
On Tue, Nov 26, 2019 at 7:00 PM Dan Seguin dan.seguin@cord3inc.com wrote:
Thanks for that, but Kerbunetes is not desired, in fact, it is not wanted.
I'll save it for future reference.
Cheers. ________________________________________ From: CentOS-devel centos-devel-bounces@centos.org on behalf of Jason Brooks jbrooks@redhat.com Sent: November 26, 2019 12:24 PM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] Centos Atomic deprecated?
On Tue, Nov 26, 2019 at 8:44 AM Gleidson Nascimento slaterx@live.com wrote:
Being part of CentOS PaaS SIG, and seeing OKD v4 taking shape, I offer
my time to assist in moving towards coreos assembler, or to help in any other way the community proposes.
As soon as we have an equivalent of coreos on CentOS, we will be able to
begin our work to release OKD v4. Therefore, this conversation is of our interest.
There's a preview release of OKD 4 out: https://github.com/openshift/okd/blob/master/README.md
They're using Fedora CoreOS for it.
Probably we will need to form a SIG to investigate this, if one wasn’t
already formed.
Thanks, Gleidson On 27 Nov 2019, 12:09 AM +1300, Dan Seguin dan.seguin@Cord3Inc.com,
wrote:
Whatever you or I find, I will share and help. As I mentioned before,
Centos 7 ATomic has huge broken tooling for re-spins. Lorax is lacking for C7. *cough* anaconda updates *cough* And many Lorax changes...
Would *love* to move to Assembler as Jason told me so long ago....
Dan ________________________________________
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-- Jason Brooks Community Architects & Infrastructure Red Hat Open Source Program Office (OSPO) https://community.redhat.com | https://osci.io
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Fri, Oct 18, 2019 at 4:53 AM Dan Seguin dan.seguin@cord3inc.com wrote:
I'm still building from an updated OSTree, to build ISOs.
CoreOS is still bleeding hemorrhaging junk with no roadmap.
Are Centos Atomic builders forever stuck with jbrooks' secret git proj? (After having to hack lorax on centos 7?)
Which git project are you talking about?
I've been a bit backed up w/ regular work recently -- the image build process is broken right now. I plan on taking a closer look at that today.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
This git:
https://github.com/CentOS/sig-atomic-buildscripts
________________________________________ From: CentOS-devel centos-devel-bounces@centos.org on behalf of Jason Brooks jbrooks@redhat.com Sent: October 18, 2019 10:00 AM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] Centos Atomic deprecated?
On Fri, Oct 18, 2019 at 4:53 AM Dan Seguin dan.seguin@cord3inc.com wrote:
I'm still building from an updated OSTree, to build ISOs.
CoreOS is still bleeding hemorrhaging junk with no roadmap.
Are Centos Atomic builders forever stuck with jbrooks' secret git proj? (After having to hack lorax on centos 7?)
Which git project are you talking about?
I've been a bit backed up w/ regular work recently -- the image build process is broken right now. I plan on taking a closer look at that today.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-- Jason Brooks Community Infrastructure Team | https://osci.io Red Hat Open Source Program Office (OSPO)
_______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Fri, Oct 18, 2019 at 7:26 AM Dan Seguin dan.seguin@cord3inc.com wrote:
This git:
Ah, that's not secret -- it might be a bit nonstandard at this point, though. I imagine it would be possible to use the same build tools that Fedora CoreOS is using, with different packages and package sources.
I did get the builds working again, though. You can find test images here: https://ci.centos.org/artifacts/sig-atomic/downstream/images/
Those images include the tree at https://buildlogs.centos.org/centos/7/atomic/x86_64/repo/. For future reference, that tree is built (and signed) each night, and when I do releases of cah, we copy from there to the release location.
Here's the fix I used to get the builds going: https://github.com/CentOS/sig-atomic-buildscripts/pull/379/commits/189667517...
We'll get a release out next week.
Jason
From: CentOS-devel centos-devel-bounces@centos.org on behalf of Jason Brooks jbrooks@redhat.com Sent: October 18, 2019 10:00 AM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] Centos Atomic deprecated?
On Fri, Oct 18, 2019 at 4:53 AM Dan Seguin dan.seguin@cord3inc.com wrote:
I'm still building from an updated OSTree, to build ISOs.
CoreOS is still bleeding hemorrhaging junk with no roadmap.
Are Centos Atomic builders forever stuck with jbrooks' secret git proj? (After having to hack lorax on centos 7?)
Which git project are you talking about?
I've been a bit backed up w/ regular work recently -- the image build process is broken right now. I plan on taking a closer look at that today.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-- Jason Brooks Community Infrastructure Team | https://osci.io Red Hat Open Source Program Office (OSPO)
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Fri, Oct 18, 2019 at 11:53:20AM +0000, Dan Seguin wrote:
CoreOS is still bleeding hemorrhaging junk with no roadmap.
That's pretty harsh, and at least in terms of "no roadmap", not really true. See https://github.com/orgs/coreos/projects/84 for work in progress. (and https://github.com/coreos/fedora-coreos-tracker for more information)
That wasn't too helpful.
I read a good post by Farak(?) that had the same questions.
Understood that all of this takes huge effort, and offered for use (and reciprocity however possible by beneficiaries).
I'd love to fix the problems in Centos Atomic 7 (anaconda and lorax), if it were possible.
________________________________________ From: CentOS-devel centos-devel-bounces@centos.org on behalf of Matthew Miller mattdm@mattdm.org Sent: October 18, 2019 10:39 AM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] Centos Atomic deprecated?
On Fri, Oct 18, 2019 at 11:53:20AM +0000, Dan Seguin wrote:
CoreOS is still bleeding hemorrhaging junk with no roadmap.
That's pretty harsh, and at least in terms of "no roadmap", not really true. See https://github.com/orgs/coreos/projects/84 for work in progress. (and https://github.com/coreos/fedora-coreos-tracker for more information)
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Fri, Oct 18, 2019 at 02:58:28PM +0000, Dan Seguin wrote:
That wasn't too helpful.
Not too helpful how? Can you be more specific about what you're looking for?
I read a good post by Farak(?) that had the same questions.
I think you mean a post by Farkas Levente, on the atomic-devel list. Scott McCarty replied to that, but I think some things got lost in translation. Scott's thinking from a the product side when he says there's "no roadmap for CRI-O and CoreOS support outside of OpenShift".
From the *community* side, Fedora CoreOS is will be a fully-official
community-supported edition — just not a Supported capital-P Product. But Fedora Atomic (and CentOS Atomic) were never that either. And, the plans for Fedora CoreOS in terms of that community support include taking the lessons learned from Atomic and from the CoreOS community to make that even better.
Have you seen https://fedoramagazine.org/introducing-fedora-coreos/ (and in particular the part about future plans)? Is that more what you're looking for?
Thanks for your considerate response.
As for what I (and some others) are looking for, it was left out from my message you quoted.
Thanks for the link.
If I can help to keep Atomic alive (with better or upgraded tools), I'd be happy to help. I understand the problems with this, mostly.
Cheers. ________________________________________ From: CentOS-devel centos-devel-bounces@centos.org on behalf of Matthew Miller mattdm@mattdm.org Sent: October 18, 2019 11:16 AM To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] Centos Atomic deprecated?
On Fri, Oct 18, 2019 at 02:58:28PM +0000, Dan Seguin wrote:
That wasn't too helpful.
Not too helpful how? Can you be more specific about what you're looking for?
I read a good post by Farak(?) that had the same questions.
I think you mean a post by Farkas Levente, on the atomic-devel list. Scott McCarty replied to that, but I think some things got lost in translation. Scott's thinking from a the product side when he says there's "no roadmap for CRI-O and CoreOS support outside of OpenShift".
From the *community* side, Fedora CoreOS is will be a fully-official
community-supported edition — just not a Supported capital-P Product. But Fedora Atomic (and CentOS Atomic) were never that either. And, the plans for Fedora CoreOS in terms of that community support include taking the lessons learned from Atomic and from the CoreOS community to make that even better.
Have you seen https://fedoramagazine.org/introducing-fedora-coreos/ (and in particular the part about future plans)? Is that more what you're looking for?
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 18/10/2019 16:27, Dan Seguin wrote:
Thanks for your considerate response.
As for what I (and some others) are looking for, it was left out from my message you quoted.
Thanks for the link.
If I can help to keep Atomic alive (with better or upgraded tools), I'd be happy to help. I understand the problems with this, mostly.
Can we use the github hosted repo to co-ordinate this ?
if there is real community interest, happy to spend some time and get the build services and nightly's back on track.
On Fri, Oct 18, 2019 at 7:36 AM Leon Fauster via CentOS-devel centos-devel@centos.org wrote:
The bug report was open by me and communicates the missing libbluray-devel package. Its closed now with "WONTFIX" ...
I did the same for libXvMC-devel and its assigned now. High probability that it will land in the CRB repo (maybe EL8.1).
Is there any explanation given? It's quite troubling that Red Hat has chosen to publish the LGPLv2 licensed binaries with source but without the devel package.
On Fri, Oct 18, 2019 at 10:23 PM Nico Kadel-Garcia nkadel@gmail.com wrote:
Is there any explanation given? It's quite troubling that Red Hat has chosen to publish the LGPLv2 licensed binaries with source but without the devel package.
Troubling? Why is it troubling? Since you mention the GPL, the GPL only requires that the source be provided, and it is.
-devel packages are an artifact of Red Hat's (and Fedora's and CentOS's) RPM packaging. The GPL doesn't mention -devel packages.
And just to set expectations, it appears the libXvMC-devel package will most likely not appear in RHEL's Code Ready Builder or CentOS's AppStream until 8.2.
--
Kaleb
Greetings,
----- Original Message -----
Troubling? Why is it troubling? Since you mention the GPL, the GPL only requires that the source be provided, and it is.
-devel packages are an artifact of Red Hat's (and Fedora's and CentOS's) RPM packaging. The GPL doesn't mention -devel packages.
And just to set expectations, it appears the libXvMC-devel package will most likely not appear in RHEL's Code Ready Builder or CentOS's AppStream until 8.2.
I was always under the impression that Red Hat does what is in the best interest of its customers... and I fail to see how not providing (some of) the devel packages is in their interest. That's just my opinion and I reserve the right to change my mind at any time. Anyhoo... what has been missing here is the "reason" (some of) the devel packages aren't being released.
It is certainly true that Red Hat has the right to do that, and unfortunate that CentOS will monkey-see-monkey-do in their efforts to be just like RHEL down to the same bugs and problems. You mention in the case of a particular package that the release is planned but not until RHEL 8.2. Given the specificity of that information, again, it begs the question of why?!? I think answering why would remove the confusion. I don't assume there is a dubious reason, but without knowing, all we have are guesses.
TYL,
On Sat, Oct 19, 2019 at 9:27 AM Scott Dowdle dowdle@montanalinux.org wrote:
. what has been missing here is the "reason" (some of) the devel packages aren't being released.
This question was answered earlier in this thread (by me even), so I'm a bit confused why you say the reason is missing.
In the case of libbluray-devel, it's because Red Hat only uses a very small piece of that library, and doesn't want to have to support the whole library, including being liable for CVEs and other bugs in the parts of the library it doesn't use.
I don't know why libXvMC-devel wasn't released originally. As they appear to have decided to go ahead and release it, apparently wasn't for the same reason as libbluray-devel.
the src.rpm is available. Build it for yourself if Red Hat and CentOS aren't providing what you want. As a maintainer of packages in the CentOS Storage SIG, even I have to build and provide packages in the SIG that Red Hat and CentOS don't provide, e.g. userspace-rcu.. (They're in EPEL, but currently CBS doesn't/can't use EPEL.) I don't understand why people have so much trouble with this.
--
Kaleb
Greetings,
----- Original Message -----
In the case of libbluray-devel, it's because Red Hat only uses a very small piece of that library, and doesn't want to have to support the whole library, including being liable for CVEs and other bugs in the parts of the library it doesn't use.
Thanks for reiterating that. It totally makes sense for the package in question.
TYL,
Am 19.10.19 um 16:28 schrieb Kaleb Keithley:
On Sat, Oct 19, 2019 at 9:27 AM Scott Dowdle <dowdle@montanalinux.org mailto:dowdle@montanalinux.org> wrote:
. what has been missing here is the "reason" (some of) the devel packages aren't being released.This question was answered earlier in this thread (by me even), so I'm a bit confused why you say the reason is missing.
In the case of libbluray-devel, it's because Red Hat only uses a very small piece of that library, and doesn't want to have to support the whole library, including being liable for CVEs and other bugs in the parts of the library it doesn't use.
I don't know why libXvMC-devel wasn't released originally. As they appear to have decided to go ahead and release it, apparently wasn't for the same reason as libbluray-devel.
the src.rpm is available. Build it for yourself if Red Hat and CentOS aren't providing what you want. As a maintainer of packages in the CentOS Storage SIG, even I have to build and provide packages in the SIG that Red Hat and CentOS don't provide, e.g. userspace-rcu.. (They're in EPEL, but currently CBS doesn't/can't use EPEL.) I don't understand why people have so much trouble with this.
I can speak only for myself. Why this missing empathy on upstreams side?
The experience forms the expectation. All major releases didn't have this issue of missing devel packages. A totally missing package is a different story and not comparable. I am rebuilding packages and building a local repository just to have a working EL8 desktop environment, so thats not the case.
Its a normal expectation having canonical packages accessible. You also get wet when going swimming. In the old days devel files were included in the main rpm. What I'm saying the main and the devel rpm packages belong together. The splitting is artificial and not releasing it is even more.
As I stated already in my bug report: "If I am correct, RH's strategy is to promote their platform to customers and customers being able to _build_ and deliver their applications (one example is the Red Hat Universal Base Image). So, its a natural expectation having the corresponding devel package ..."
Do not get me wrong. You guys did a great work. Despite the missing statement why this (business?) decision (besides the statement you made for a specific package), if you do not want to support a package then do not release it at all ...
plainrhel8$ LANG=C rpm -ev libbluray --test error: Failed dependencies: libbluray.so.2()(64bit) is needed by (installed) gvfs-1.36.2-2.el8_0.1
Anyway, I think we all have a notion about how the iceberg looks under the water :-)
Happy Weekend!
Leon
On la, 19 loka 2019, Leon Fauster via CentOS-devel wrote:
Am 19.10.19 um 16:28 schrieb Kaleb Keithley:
On Sat, Oct 19, 2019 at 9:27 AM Scott Dowdle <dowdle@montanalinux.org mailto:dowdle@montanalinux.org> wrote:
. what has been missing here is the "reason" (some of) the devel packages aren't being released.
This question was answered earlier in this thread (by me even), so I'm a bit confused why you say the reason is missing.
In the case of libbluray-devel, it's because Red Hat only uses a very small piece of that library, and doesn't want to have to support the whole library, including being liable for CVEs and other bugs in the parts of the library it doesn't use.
I don't know why libXvMC-devel wasn't released originally. As they appear to have decided to go ahead and release it, apparently wasn't for the same reason as libbluray-devel.
the src.rpm is available. Build it for yourself if Red Hat and CentOS aren't providing what you want. As a maintainer of packages in the CentOS Storage SIG, even I have to build and provide packages in the SIG that Red Hat and CentOS don't provide, e.g. userspace-rcu.. (They're in EPEL, but currently CBS doesn't/can't use EPEL.) I don't understand why people have so much trouble with this.
I can speak only for myself. Why this missing empathy on upstreams side?
The experience forms the expectation. All major releases didn't have this issue of missing devel packages. A totally missing package is a different story and not comparable. I am rebuilding packages and building a local repository just to have a working EL8 desktop environment, so thats not the case.
Its a normal expectation having canonical packages accessible. You also get wet when going swimming. In the old days devel files were included in the main rpm. What I'm saying the main and the devel rpm packages belong together. The splitting is artificial and not releasing it is even more.
I think this analogy is incorrectly used here. *You* get wet when going swimming but it doesn't mean that somebody else should have responsibility to dry you off. A way you dry off is not dictated by the way you became wet.
As I stated already in my bug report: "If I am correct, RH's strategy is to promote their platform to customers and customers being able to _build_ and deliver their applications (one example is the Red Hat Universal Base Image). So, its a natural expectation having the corresponding devel package ..."
Do not get me wrong. You guys did a great work. Despite the missing statement why this (business?) decision (besides the statement you made for a specific package), if you do not want to support a package then do not release it at all ...
plainrhel8$ LANG=C rpm -ev libbluray --test error: Failed dependencies: libbluray.so.2()(64bit) is needed by (installed) gvfs-1.36.2-2.el8_0.1
Anyway, I think we all have a notion about how the iceberg looks under the water :-)
Indeed. A package might be required by another supported package but that one would only use a limited and well-confined functionality under the cover. A distribution vendor (in this case Red Hat) might make a decision to limit its support to only that subset and indirectly, via a its dependency. I wish we had a way to properly declare and provide such technical support statement validated by build systems but we don't have it, so a whole set of -devel packages got slashed off.
Am 20.10.19 um 12:42 schrieb Alexander Bokovoy:
On la, 19 loka 2019, Leon Fauster via CentOS-devel wrote:
Am 19.10.19 um 16:28 schrieb Kaleb Keithley:
On Sat, Oct 19, 2019 at 9:27 AM Scott Dowdle <dowdle@montanalinux.org mailto:dowdle@montanalinux.org> wrote:
. what has been missing here is the "reason" (some of) the devel packages aren't being released.
This question was answered earlier in this thread (by me even), so I'm a bit confused why you say the reason is missing.
In the case of libbluray-devel, it's because Red Hat only uses a very small piece of that library, and doesn't want to have to support the whole library, including being liable for CVEs and other bugs in the parts of the library it doesn't use.
I don't know why libXvMC-devel wasn't released originally. As they appear to have decided to go ahead and release it, apparently wasn't for the same reason as libbluray-devel.
the src.rpm is available. Build it for yourself if Red Hat and CentOS aren't providing what you want. As a maintainer of packages in the CentOS Storage SIG, even I have to build and provide packages in the SIG that Red Hat and CentOS don't provide, e.g. userspace-rcu.. (They're in EPEL, but currently CBS doesn't/can't use EPEL.) I don't understand why people have so much trouble with this.
I can speak only for myself. Why this missing empathy on upstreams side?
The experience forms the expectation. All major releases didn't have this issue of missing devel packages. A totally missing package is a different story and not comparable. I am rebuilding packages and building a local repository just to have a working EL8 desktop environment, so thats not the case.
Its a normal expectation having canonical packages accessible. You also get wet when going swimming. In the old days devel files were included in the main rpm. What I'm saying the main and the devel rpm packages belong together. The splitting is artificial and not releasing it is even more.
I think this analogy is incorrectly used here. *You* get wet when going swimming but it doesn't mean that somebody else should have responsibility to dry you off. A way you dry off is not dictated by the way you became wet.
As I stated already in my bug report: "If I am correct, RH's strategy is to promote their platform to customers and customers being able to _build_ and deliver their applications (one example is the Red Hat Universal Base Image). So, its a natural expectation having the corresponding devel package ..."
Do not get me wrong. You guys did a great work. Despite the missing statement why this (business?) decision (besides the statement you made for a specific package), if you do not want to support a package then do not release it at all ...
plainrhel8$ LANG=C rpm -ev libbluray --test error: Failed dependencies: libbluray.so.2()(64bit) is needed by (installed) gvfs-1.36.2-2.el8_0.1
Anyway, I think we all have a notion about how the iceberg looks under the water :-)
Indeed. A package might be required by another supported package but that one would only use a limited and well-confined functionality under the cover. A distribution vendor (in this case Red Hat) might make a decision to limit its support to only that subset and indirectly, via a its dependency. I wish we had a way to properly declare and provide such technical support statement validated by build systems but we don't have it, so a whole set of -devel packages got slashed off.
What about custom software builds that use exactly only this supported part of the library? It can not be build because of the missing header files!
Take a look at the openssl package; if it is not supported, its cleaned out (hobble version) and the full output of the build process are provided (all packages).
Actually we based this discussion on the explanation for the case of libbluray-devel but what about the others packages?
Examples are (incomplete list): * avahi-glib-devel * avahi-gobject-devel * avahi-tools * avahi-ui * avahi-ui-devel * gfbgraph-devel * liba52-devel * libdmapsharing-devel * libdvdnav-devel * libuv-devel * libXvMC-devel * qgpgme-devel * rest-devel * totem-pl-parser-devel
A distribution vendor have of course the right to limit the support but this specific case (missing devel rpm) leaves a bad taste on customers side and results in a bad experience. IMHO this experience contradicts RH's strategy pushing this platform ...
-- Leon
On su, 20 loka 2019, Leon Fauster via CentOS-devel wrote:
Am 20.10.19 um 12:42 schrieb Alexander Bokovoy:
On la, 19 loka 2019, Leon Fauster via CentOS-devel wrote:
Am 19.10.19 um 16:28 schrieb Kaleb Keithley:
On Sat, Oct 19, 2019 at 9:27 AM Scott Dowdle <dowdle@montanalinux.org mailto:dowdle@montanalinux.org> wrote:
. what has been missing here is the "reason" (some of) the devel packages aren't being released.
This question was answered earlier in this thread (by me even), so I'm a bit confused why you say the reason is missing.
In the case of libbluray-devel, it's because Red Hat only uses a very small piece of that library, and doesn't want to have to support the whole library, including being liable for CVEs and other bugs in the parts of the library it doesn't use.
I don't know why libXvMC-devel wasn't released originally. As they appear to have decided to go ahead and release it, apparently wasn't for the same reason as libbluray-devel.
the src.rpm is available. Build it for yourself if Red Hat and CentOS aren't providing what you want. As a maintainer of packages in the CentOS Storage SIG, even I have to build and provide packages in the SIG that Red Hat and CentOS don't provide, e.g. userspace-rcu.. (They're in EPEL, but currently CBS doesn't/can't use EPEL.) I don't understand why people have so much trouble with this.
I can speak only for myself. Why this missing empathy on upstreams side?
The experience forms the expectation. All major releases didn't have this issue of missing devel packages. A totally missing package is a different story and not comparable. I am rebuilding packages and building a local repository just to have a working EL8 desktop environment, so thats not the case.
Its a normal expectation having canonical packages accessible. You also get wet when going swimming. In the old days devel files were included in the main rpm. What I'm saying the main and the devel rpm packages belong together. The splitting is artificial and not releasing it is even more.
I think this analogy is incorrectly used here. *You* get wet when going swimming but it doesn't mean that somebody else should have responsibility to dry you off. A way you dry off is not dictated by the way you became wet.
As I stated already in my bug report: "If I am correct, RH's strategy is to promote their platform to customers and customers being able to _build_ and deliver their applications (one example is the Red Hat Universal Base Image). So, its a natural expectation having the corresponding devel package ..."
Do not get me wrong. You guys did a great work. Despite the missing statement why this (business?) decision (besides the statement you made for a specific package), if you do not want to support a package then do not release it at all ...
plainrhel8$ LANG=C rpm -ev libbluray --test error: Failed dependencies: libbluray.so.2()(64bit) is needed by (installed) gvfs-1.36.2-2.el8_0.1
Anyway, I think we all have a notion about how the iceberg looks under the water :-)
Indeed. A package might be required by another supported package but that one would only use a limited and well-confined functionality under the cover. A distribution vendor (in this case Red Hat) might make a decision to limit its support to only that subset and indirectly, via a its dependency. I wish we had a way to properly declare and provide such technical support statement validated by build systems but we don't have it, so a whole set of -devel packages got slashed off.
What about custom software builds that use exactly only this supported part of the library? It can not be build because of the missing header files!
Like I said above already, we don't have a way to properly declare and provide such fine-tuned technical support statement validated by a build system. A granularity is what it is, a whole -devel package.
Take a look at the openssl package; if it is not supported, its cleaned out (hobble version) and the full output of the build process are provided (all packages).
Actually we based this discussion on the explanation for the case of libbluray-devel but what about the others packages?
We can argue for every package but at the end, there are teams that own maintenance of the packages. They make the decisions and those decisions then get through product management. Sometimes they get cut in the middle, sometimes they already put down by the teams themselves.
Examples are (incomplete list):
- avahi-glib-devel
- avahi-gobject-devel
- avahi-tools
- avahi-ui
- avahi-ui-devel
- gfbgraph-devel
- liba52-devel
- libdmapsharing-devel
- libdvdnav-devel
- libuv-devel
- libXvMC-devel
- qgpgme-devel
- rest-devel
- totem-pl-parser-devel
A distribution vendor have of course the right to limit the support but this specific case (missing devel rpm) leaves a bad taste on customers side and results in a bad experience. IMHO this experience contradicts RH's strategy pushing this platform ...
I think a productive way would be to file bugs asking to get the packages in, with explanation why they are needed and how they would be used.
I did the same for quota-devel already -- its lack doesn't allow us to test the quota-related functionality in Samba CI upstream, for example.
On Sun, Oct 20, 2019 at 8:24 AM Alexander Bokovoy abokovoy@redhat.com wrote:
A distribution vendor have of course the right to limit the support but this specific case (missing devel rpm) leaves a bad taste on customers side and results in a bad experience. IMHO this experience contradicts RH's strategy pushing this platform ...
I think a productive way would be to file bugs asking to get the packages in, with explanation why they are needed and how they would be used.
I did the same for quota-devel already -- its lack doesn't allow us to test the quota-related functionality in Samba CI upstream, for example.
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
Do feel free to play with my backports of Samba, with quota-devel compiled into a local yum repository for local builds with CentOS 8 or RHEL 8, over at https://github.com/nkadel/samba4repo . The process of porting it to CentOS 8 was complicated by Red Hat's decision to activate modularity in an awkwardly integrated fashion, and requires resetting the mock configurations to "best=0", documented at https://bugzilla.redhat.com/show_bug.cgi?id=1756681 .And I've published pull requiest for that to the mock developers.
This decision to stop including the devel package means I've had to include a local build tree for "quota" in my Samba development environment, and it's likely to break my development environment when quota gets even a minor version update and my locally published quota-devel package no longer matches. I don't want to waste my time on this sort of thing, and I do pay for RHEL licenses. I hope that CentOS elects not to emulate this silliness and puts the quota-edevel package in the "PowerTools" channel.
-
Alexander Bokovoy -
Anthony Alba -
Dan Seguin -
Gleidson Nascimento -
Jason Brooks -
Kaleb Keithley -
Karanbir Singh -
Leon Fauster -
Matthew Miller -
Mihai Moldovan -
Neal Gompa -
Nico Kadel-Garcia -
Scott Dowdle -
Spyros Trigazis -
Thomas Oulevey -
Xavier Bachelot