Am 12.08.20 um 16:55 schrieb Johnny Hughes:
On 8/11/20 12:10 PM, Troy Dawson wrote:
On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson tdawson@redhat.com wrote:
On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes johnny@centos.org wrote:
On 8/10/20 3:41 PM, Troy Dawson wrote:
On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski orion@nwra.com wrote:
Is there anything I can do to help out with missing -devel packages in CentOS 8? I'm waiting for a number of them, e.g.:
Hi Orion, It helps if it is linked to this ticket. https://bugs.centos.org/view.php?id=16492 Although nothing has happened there for 5 months.
To be clear, there is two definitions of "missing -devel packages"
There are the ones that have never shown up anywhere (I'm still waiting on 4 I believe)
And then there are the ones that originally showed up, and we were able to build from them in EPEL8, but then when RHEL 8.2 came along, the EPEL8 packages are still the old ones from RHEL 8.1. https://pagure.io/releng/issue/9580
And while we would love to just publish these .. we can not.
There are competing goals here. Bit for bit like RHEL .. RHEL does not have the SRPMS, we should not.
Someone wants the SRPMS .. so they want us to like RHEL .. except when they don't. All our build system and where we pull info assumes we need to be the same. Introducing things were we are not is HARD .. especially in el8 as we HAVE to use koji and mbox and pungi to build. Introducing differences into compose configurations for pungi for releases is HARD .. it has follow on impacts .. and we need a system in place to make it continue to work when we get updated compose files in the future.
We have people working on this, but it is just not a priority compared to getting things released on time and builds working properly. It is not just a simple .. push a couple packages somewhere.
You already have them published, that work is done. http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/ http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
It doesn't say it in the ticket, but from conversations the rsync area that was setup for EPEL8 to sync that over, something happened and they can't sync anymore. I don't know the details. It's possible that the syncing is already fixed, and they just need to restart and/or update their script.
Troy
Turns out the syncing was fixed, but the ticket not closed. Sorry for all the noise. If I had just tried to rebuild my package again, I would have seen it was fixed.
Troy
Thanks Troy .. as i said, we did get SOME packages added and they SHOULD stay fixed.
But some -devel packages are also not fixed, as there are lots of things that need to be modified in the automation to keep them fixed.
I am not so deep in this "koji mbox pungi" infra thing but like other devel packages, they are also the output of the build process and survive the repo build, so why not letting them also there where they already are? I can not believe that this is hardcoded in "koji mbox pungi" :-)?
Ok, the argument is - RHEL is ... and CentOS will be also so. Okay. (Side note does Upstream have a rhelplus like centosplus repo? So, no justification to have not an full populated Devel repo?)
While the packages are _actively_ deleted (process step before repo build). Why not substitute "rm $1" with "mv -t Devel $1". An automatic process and no need to request packages, like here:
https://bugs.centos.org/view_all_set.php?sort_add=category_id&dir_add=DE...
The most requests for such devel packages are done because people are building others packages that depend on (BuildRequires) also CentOS need them. Well, they are devel rpms right. But what I wanted to say is they are mostly not requested to get installed for ever and maybe produce bug reports etc. (exactly this case is not supported, claimed by upstream).
BTW, you already do the right thing in putting a warning into the reponame/file.
Building the SRPM is straight forward and the people have then the missing devel packages. So why this hassle?
As I said, I do not know the internal process. Its just my mental model that gets here depicted from a point of view outside of the project.
-- Thanks, Leon