Bug 2305674

Summary:	Move rubygem-asciidoctor to RHEL CRB
Product:	[Fedora] Fedora EPEL	Reporter:	Marián Konček <mkoncek>
Component:	rubygem-asciidoctor	Assignee:	Dan Allen <dan.j.allen>
Status:	NEW ---	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	epel9	CC:	dan.j.allen, dominik.mierzejewski, epel-packagers-sig, logans, orion, vondruch
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		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:

Description Marián Konček 2024-08-19 09:00:09 UTC

rubygem-asciidoctor is a generally useful package for building many projects including other packages present in RHEL CRB. Currently this package is present in the EPEL repository. However using it requires including extra repositories on the consumer's side.

This bug is to discuss the feasibility of moving the package to the CRB variant and discontinuing the EPEL version in RHEL 9.

Example: CI of a package used for building Java packages in RHELs and Fedoras (currently uses the Buildroot repository, could have used EPEL):
https://github.com/fedora-java/jurand/blob/b9c5df76d3c59204c2683a268a6cd4f6a41ccdf1/.github/workflows/ci.yaml

Comment 1 Orion Poplawski 2024-09-19 03:28:23 UTC

This should be filed at https://issues.redhat.com/ against centos stream

Comment 2 Vít Ondruch 2024-09-19 08:24:51 UTC

(In reply to Orion Poplawski from comment #1)
> This should be filed at https://issues.redhat.com/ against centos stream

Yes, if it was decided what is the preferred way. This is to solicit feedback from EPEL maintainers and users, what would be their preference.

IOW maintaining this package in EPEL has its advantages, such as bigger freedom for rebases, community maintenance independent from RH, etc. OTOH the package is in CS BuildRoot and it could be made more visible / accessible by moving it from BuildRoot into CRB without any additional promises from RH side. This could free some resources from EPEL maintainers for possibly more important stuff.

Comment 3 Orion Poplawski 2024-09-19 13:06:04 UTC

AH.  Well, personally I would just keep it in EPEL - for the reasons you mentioned.

Comment 4 Marián Konček 2024-09-24 10:19:11 UTC

I don't have strong opinnions on this as long as it is available in EPEL.
However from my point of view this package should be somehow available in plain RHEL and I don't understand how no one has requested it yet...

Comment 5 Dominik Mierzejewski 2025-10-29 09:39:32 UTC

(In reply to Vít Ondruch from comment #2)
> (In reply to Orion Poplawski from comment #1)
> > This should be filed at https://issues.redhat.com/ against centos stream
> 
> Yes, if it was decided what is the preferred way. This is to solicit
> feedback from EPEL maintainers and users, what would be their preference.
> 
> IOW maintaining this package in EPEL has its advantages, such as bigger
> freedom for rebases, community maintenance independent from RH, etc. OTOH
> the package is in CS BuildRoot and it could be made more visible /
> accessible by moving it from BuildRoot into CRB without any additional
> promises from RH side. This could free some resources from EPEL maintainers
> for possibly more important stuff.

It looks like the package is practically unmaintained as even the rawhide
branch is lagging two years and 6 releases behind upstream.

I'd like to see it in RHEL as then I can use it as part of internal build
pipeline (EPEL is frowned upon due to lack of support from RH).