Bug 2104519
| Summary: | Please branch and build libwebp-tools in epel9. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Brad Patton <brad> |
| Component: | libwebp | Assignee: | Sandro Mani <manisandro> |
| Status: | CLOSED CANTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | brad, carl, manisandro |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-07-20 11:50:02 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: | |||
|
Description
Brad Patton
2022-07-06 14:16:30 UTC
This will need to be a new package as libwebp is already an EL package: $ fedpkg request-branch epel9 Could not execute request_branch: This package is already an EL package, therefore it cannot be in EPEL. If this is a mistake or you have an exception, please contact the Release Engineering team (In reply to Sandro Mani from comment #1) > This will need to be a new package as libwebp is already an EL package: Just wanted to make sure we are talking about the same package. Yes, libwebp is indeed in EL. But I'm asking about libwebp-tools which is a different package that contains tools like "cwebp" and "gif2webp". If this shouldn't be in EPEL, should I make the request in the RHEL9 product specifically? Thanks! The simplest thing would be if it were part of the EL package. Alternatively, a new dedicate package needs to be added to EPEL, which builds just the tools against the EL libwebp. I can help clarify this a little bit. The RPMs you install on your system are built from something called source RPMs (SRPMs). One SRPM can create multiple RPMs, also known as subpackages. All of our tools and workflows key off the SRPM name. For example, the SRPM name is used for: - the bugzilla component field - the filename of the spec file - the name of the distgit (package source) repo EPEL packages are not allowed to conflict or duplicate RHEL packages by policy [0]. This includes the SRPM. The libwebp and libwebp-tools RPMs are both built from the libwebp SRPM [1]. When using fedpkg to request an epel9 branch, it checks if the distgit repo name already exists in CentOS Stream 9 compose metadata [2]. If it does, then that means the package is already in RHEL (or is expected to be in the next minor release). The libwebp SRPM is built for RHEL 9, but currently only libwebp and libwebp-devel are shipped in the distro. As you found in bug 2121943, it's possible to request an unshipped package be included. Another option is what Sandro mentioned, creating an EPEL-only package with a different SRPM name that only provides the subpackages that are not in RHEL. Both of these solutions are discussed in more detail in the EPEL docs [3]. [0] https://docs.fedoraproject.org/en-US/epel/epel-policy/ [1] https://kojihub.stream.centos.org/koji/buildinfo?buildID=11840 [2] https://pagure.io/fedpkg/blob/d37d562a416e91e140322045283d1c5398c28ad6/f/fedpkg/utils.py#_388-420 [3] https://docs.fedoraproject.org/en-US/epel/epel-policy-missing-sub-packages/ |