I use the Open Build Service on build.opensuse.org to build packages for CentOS (and other distros), including the Cawbird Twitter client.
Cawbird is currently failing for CentOS 8 (Streams and non-Streams) because nothing provides `pkgconfig(rest-0.7)`.
Looking on pkgs.org, I can see rest-0.8.1-2.el8.x86_64.rpm for CentOS 8 when searching "rest"[1] but only see rest-devel packages in OKey and Raven repos[2].
I'm vaguely familiar with Koji from Fedora and so I found what appears to be the CentOS Koji build server. It appears that rest-devel was last built in late November[3] and is flagged as "expired" but the main rest package was built two days ago[4] (but still flagged as "expired"!)
Is this normal? Does anyone know why there would be binary/library packages but not devel packages published?
Thanks,
IBBoard
[1] https://pkgs.org/search/?q=rest [2] https://pkgs.org/search/?q=rest-devel [3] https://koji.mbox.centos.org/koji/rpminfo?buildrootOrder=-create_event_time&... [4] https://koji.mbox.centos.org/koji/rpminfo?buildrootOrder=-create_event_time&...
* On 12/14/21 9:54 PM, IBBoard wrote:
I'm vaguely familiar with Koji from Fedora and so I found what appears to be the CentOS Koji build server. It appears that rest-devel was last built in late November[3] and is flagged as "expired" but the main rest package was built two days ago[4] (but still flagged as "expired"!)
You're confusing things.
Both packages were built back in 2019 and not updated since. See their "Buildroot" tag.
What you are referring to are *other* buildroots that USE the package(s) as dependencies. For instance, the last build that used rest was two days ago - a libreoffice build.
I don't know where you'd see the expired tag (which would, as far as I remember, indicate that the package was updated and that the build you're looking at is obsolete or that the package was completely removed from the distribution), but it certainly shouldn't be expired.
Is this normal? Does anyone know why there would be binary/library packages but not devel packages published?
The rest package is part of AppStream.
Curiously, rest-devel is not there. And that does sound like a bug.
Thanks for bringing that up. Hopefully someone else can help you out and take a look at that.
Mihai
On 14/12/2021 21:43, Mihai Moldovan wrote:
- On 12/14/21 9:54 PM, IBBoard wrote:
I'm vaguely familiar with Koji from Fedora and so I found what appears to be the CentOS Koji build server. It appears that rest-devel was last built in late November[3] and is flagged as "expired" but the main rest package was built two days ago[4] (but still flagged as "expired"!)
You're confusing things.
Both packages were built back in 2019 and not updated since. See their "Buildroot" tag.
What you are referring to are *other* buildroots that USE the package(s) as dependencies. For instance, the last build that used rest was two days ago - a libreoffice build.
Okay - thanks for clarifying. I'd taken those numbers to be versions (e.g. dist-c8-stream-build-80100-30777 is CentOS 8 Streams build 80100) rather than just build root numbers.
I don't know where you'd see the expired tag (which would, as far as I remember, indicate that the package was updated and that the build you're looking at is obsolete or that the package was completely removed from the distribution), but it certainly shouldn't be expired.
The right-hand column in the two Koji links is "State". Every single one has a calendar icon, and if you hover over it then it says "expired". But from what you've said then presumably that's the build root and not the build of the package that expired.
On Tue, Dec 14, 2021 at 3:55 PM IBBoard centosdevel@ibboard.co.uk wrote:
Is this normal? Does anyone know why there would be binary/library packages but not devel packages published?
The shipping of devel packages can alter a package's ABI support guidance[0]. If you need a devel package, please submit a request for it to become part of the release compose, either as part of AppStream or CRB:
Quick link for EL8 (I have an identical one for EL9): https://da.gd/c8s-bugs
Should that be rejected, you can request EPEL ship the devel subpackage instead[1][2].
[0] https://access.redhat.com/articles/rhel8-abi-compatibility [1] https://docs.fedoraproject.org/en-US/epel/epel-package-request/ [2] https://fedoraproject.org/wiki/EPEL/FAQ#RHEL_8_has_binaries_in_the_release.2...
On 14/12/2021 22:02, Mike Rochefort wrote:
On Tue, Dec 14, 2021 at 3:55 PM IBBoard centosdevel@ibboard.co.uk wrote:
Is this normal? Does anyone know why there would be binary/library packages but not devel packages published?
The shipping of devel packages can alter a package's ABI support guidance[0].
Ah, so standard RHEL/CentOS practice is to provide libraries for internal dependencies without supporting building against them? I hadn't realised. I'm used to every package in a distro having a devel.
It used to be there, so I don't know what changed. Maybe the move from CentOS8 to Streams?
I might request the devel package, but given that I'm just building a small Twitter app with a low CentOS-based audience then it seems like quite a large commitment to put on CentOS to support building against the library.
On Wed, Dec 15, 2021, at 13:28, IBBoard wrote:
On 14/12/2021 22:02, Mike Rochefort wrote:
On Tue, Dec 14, 2021 at 3:55 PM IBBoard centosdevel@ibboard.co.uk wrote:
Is this normal? Does anyone know why there would be binary/library packages but not devel packages published?
The shipping of devel packages can alter a package's ABI support guidance[0].
Ah, so standard RHEL/CentOS practice is to provide libraries for internal dependencies without supporting building against them? I hadn't realised. I'm used to every package in a distro having a devel.
It used to be there, so I don't know what changed. Maybe the move from CentOS8 to Streams?
I might request the devel package, but given that I'm just building a small Twitter app with a low CentOS-based audience then it seems like quite a large commitment to put on CentOS to support building against the library.
If you're working on something of your own, you're also always free to download those -devel packages from the buildsystem (even for things that are not in one of the published repositories on the mirrors).
All of the RPMs are available on the build page you found earlier: https://kojihub.stream.rdu2.redhat.com/koji/buildinfo?buildID=12950
devel packages are also included in the latest buildroot repos available here: https://kojihub.stream.rdu2.redhat.com/kojifiles/repos/c9s-build/latest/
--Brian
On Wed, Dec 15, 2021, at 14:16, Brian Stinson wrote:
On Wed, Dec 15, 2021, at 13:28, IBBoard wrote:
On 14/12/2021 22:02, Mike Rochefort wrote:
On Tue, Dec 14, 2021 at 3:55 PM IBBoard centosdevel@ibboard.co.uk wrote:
Is this normal? Does anyone know why there would be binary/library packages but not devel packages published?
The shipping of devel packages can alter a package's ABI support guidance[0].
Ah, so standard RHEL/CentOS practice is to provide libraries for internal dependencies without supporting building against them? I hadn't realised. I'm used to every package in a distro having a devel.
It used to be there, so I don't know what changed. Maybe the move from CentOS8 to Streams?
I might request the devel package, but given that I'm just building a small Twitter app with a low CentOS-based audience then it seems like quite a large commitment to put on CentOS to support building against the library.
If you're working on something of your own, you're also always free to download those -devel packages from the buildsystem (even for things that are not in one of the published repositories on the mirrors).
All of the RPMs are available on the build page you found earlier: https://kojihub.stream.rdu2.redhat.com/koji/buildinfo?buildID=12950
devel packages are also included in the latest buildroot repos available here: https://kojihub.stream.rdu2.redhat.com/kojifiles/repos/c9s-build/latest/
--Brian
Ermm, sorry about that, my URLs got translated: https://kojihub.stream.centos.org/koji/buildinfo?buildID=12950 and https://kojihub.stream.centos.org/kojifiles/repos/c9s-build/latest/ respectively.
--Brian