Yes, this would also apply to that scenario. You can create a
lame-epel package that has a lame subpackage, as long as none of the
files conflict with lame-devel and lame-libs from RHEL8. You would
also want to relax the requirement on lame-libs by removing the
%{release}, so that way you can bump the release on the epel package
and still have the requirement satisfied by the RHEL lame-libs.
-Requires: %{name}-libs = %{version}-%{release}
+Requires: %{name}-libs = %{version}
On Thu, Jul 1, 2021 at 5:31 PM Sérgio Basto <sergio@xxxxxxxxxx> wrote:
>
> Hi,
>
> Sorry, this may be a little Off-topic but we notice that lame package
> from RHEL 8 (1) is not shipping lame package with binaries and in this
> case lame-devel is provided along with lame-libs , can we apply the
> same rules ? is completely a different situation ?
>
>
> (1)
> https://git.centos.org/rpms/lame/blob/c8/f/SPECS/lame.spec
>
>
> On Thu, 2021-07-01 at 15:05 -0700, Troy Dawson wrote:
> > I believe this is a recommendation, versus a policy.
> > I wanted to get people's thoughts on it, and if ya'll like it, put it
> > in the documentation.
> > ----
> > In Red Hat Enterprise Linux (RHEL) 8, Red Hat decided to not ship all
> > packages that are built from RHEL spec files. This will also be true
> > of RHEL 9, and possibly future RHEL releases. These missing packages
> > are usually -devel packages and may impact an EPEL package build.
> > If your EPEL package is impacted by a missing -devel package, do the
> > following.
> >
> > 1 - Request the package be added to RHEL 8 and 9 CRB repository.
> > -- To initiate this process, please file a bug in
> > https://bugzilla.redhat.com and request it be added to RHEL 8 and 9.
> > Report the bug against the "CentOS Stream" version of the "Red Hat
> > Enterprise Linux 8" and/or "Red Hat Enterprise Linux 9" product.
> > -- Be sure to say that it is impacting an EPEL build, and which package
> > it is impacting.
> >
> > 2 - Create an epel package that only has the missing packages.
> > -- Be prepared to maintain this package as long as it is needed.
> > -- It is recommended that you name it <package>-epel
> > -- It is recommended that you add the epel-packaging-sig group as a co-
> > maintainer
> > -- It qualifies for an exception to the review process[1] so you can
> > request the repo with
> > --- fedpkg request-repo --exception <package>-epel
> > -- If you need help building this, ask for help. We have some
> > examples.
> >
> > 3 - When/If the missing package(s) are added to RHEL CRB, retire your -
> > epel package.
> >
> > ---
> > Sorry, this is a little rushed. I wanted to get something out sooner,
> > rather than later.
> >
> > Troy
> >
> > [1] -
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process
> > - Third bullet point
>
> --
> Sérgio M. B.
> _______________________________________________
> epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
--
Carl George
_______________________________________________
epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
