Bug 2305674 - Move rubygem-asciidoctor to RHEL CRB
Summary: Move rubygem-asciidoctor to RHEL CRB
Keywords:
Status: NEW
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: rubygem-asciidoctor
Version: epel9
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Dan Allen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-08-19 09:00 UTC by Marián Konček
Modified: 2024-09-24 10:19 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)

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...


Note You need to log in before you can comment on or make changes to this bug.