Bug 2012355
| Summary: | Missing gtksourceview4-devel package | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Mike Rochefort <mroche> |
| Component: | gtksourceview4 | Assignee: | Christian Hergert <chergert> |
| Status: | CLOSED NEXTRELEASE | QA Contact: | Tomas Pelka <tpelka> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | CentOS Stream | CC: | bstinson, carl, chergert, dofiy12982, fedora, jwboyer, ngompa13, redhat-bugzilla, sbarcomb, tpelka, tpopela, vikpatil, vrajput |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | gtksourceview4-4.8.1-3.el9 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-08-02 11:07:22 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 2100267 | ||
|
Description
Mike Rochefort
2021-10-08 23:57:57 UTC
We've generally not brought in the -devel packages for GtkSourceView because that'd require further maintenance as a platform library beyond our own internal use for applications we ship. I also think that at this point we're moving largely to Flatpak for end-user applications (where they are free to include and depend on whatever version they like). To me, I would interpret that as a push to move away towards introducing this. Given that gedit can already be distributed as a Flatpak, is there a reason that Pluma cannot be as well? My understanding is that it was a fork of gedit long ago. > I also think that at this point we're moving largely to Flatpak for end-user applications Does this mean gedit and all other software that requires gtksourceview4 is being converted to flatpak-only in rhel9? If that is the case, gtksourceview4 could be removed and then epel9 would be free to ship gtksourceview4 and gtksourceview4-devel for any epel9 rpms to build against. If that's not happening, then including only gtksourceview4 and not gtksourceview4-devel has the end result of blocking epel9 packages from being created. Adding gtksourceview4-devel to CRB would unblock these packages. epel9 is prohibited by policy from shipping gtksourceview4-devel itself because the srpm name is currently part of rhel9. I understand that this has ACG implications for the corresponding library in AppStream, but considering gtksourceview4 is already bound to major version 4 by virtue of its name, are there actual concerns with maintaining its ABI compatibility for the lifetime of rhel9? If there are significant ABI concerns, would you consider shipping gtksourceview4-devel and pursuing an ACG 4 classification for gtksourceview4? > Given that gedit can already be distributed as a Flatpak, is there a reason that Pluma cannot be as well? Whether or not pluma can be distributed as a flatpak is immaterial to this request. The request is to ship gtksourceview4-devel in CRB so that pluma can be shipped in epel9 (epel9-next initially). I also would like to point out that we ship gtksourceview3-devel in rhel8 CRB, so this can be viewed as a regression of sorts. Adding gtksourceview4-devel to CRB is the preferred outcome to make rhel9 a usable platform. I honestly have no idea. I haven't done any of the packaging or gating for GtkSourceView at any point in RHEL, despite somehow being the contact. It would be a research project first to determine for what it was added in the first place and/if that should stay or be dropped. I have to maintain ABI of the -4 series upstream, and that won't be changing, I just don't want to be managing unnecessary packaging, especially since I've done zero RHEL packages so far. MATE Pluma also depends on gtksourceview4-devel. May I kindly ask you to provide the package via CRB? For building pluma for epel8 we need gtksourceview4-4.6.1 . I simply use gtksourceview4-4.6.1-2.fc33.src.rpm for a local rebuild for rocky 8, which works fine. I am fedora MATE Maintainer and i am happy to help with co-maintaining for epel8/9 branches. Thank you And no, i don't want to move to flatpack, snapd or docker for pluma, due a lack of time. I am maintaining the Make stack alone, so using flatpack is a luxury ;) > It would be a research project first to determine for what it was added in the first place and/if that should stay or be dropped.
What was the result of this research? Can gtksourceview4-devel be shipped? This is actively hampering EPEL9 growth, which in turn hampers RHEL9 adoption.
Cross-filed case 03253468 at the Red Hat customer portal to hopefully help this also from the paying side of a Red Hat customer. gtksourceview4 is already ACG2, so shipping gtksourceview4-devel in CRB (which is unsupported content) should have no support impact. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/package_manifest/repositories#AppStream-repository Any news on this? Given Red Hat unfortunately didn't progress here for about a month (even with a business case opened), I've created gtksourceview4-epel which provides gtksourceview4-devel for EPEL 9. The process to move the package to CRB for 9.1 is in progress. |