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/#... - Third bullet point
On Thu, Jul 01, 2021 at 03:05:50PM -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 cannot be named <package> (ie, the same name as the rhel source package name).
-- 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.
-- keep it in sync with the RHEL version, upgrade when they do.
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.
Looks great to me aside the nitpicks above.
kevin
This looks great so far to me.
Should we also encourage/require modifying the release to have a leading `0.` so that it will upgrade cleanly when/if RHEL adds the relevant subpackage?
On Thu, Jul 1, 2021 at 5:30 PM Kevin Fenzi kevin@scrye.com wrote:
On Thu, Jul 01, 2021 at 03:05:50PM -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 cannot be named <package> (ie, the same name as the rhel source package name).
-- 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.
-- keep it in sync with the RHEL version, upgrade when they do.
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.
Looks great to me aside the nitpicks above.
kevin _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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@lists.fedoraproject... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
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/#... - Third bullet point
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@serjux.com 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/#...
- Third bullet point
-- Sérgio M. B. _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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@lists.fedoraproject... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 7/1/21 4:05 PM, 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 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
So, I've decided to try this with utf8proc. I've requested the utf8proc-epel package and now requested an epel8 branch (and will retire the rawhide branch).
These are the changes I have made, does this seem correct? Notes on changes:
* We are not shipping binaries, so need to disable the debug package * Need to change Name and %{name} * Need to explicitly name the devel package * Need to use relative Requires for the main package. Both to allow RHEL to update and (in this case) to deal with module release tags * Remove the files installed for the main package * Remove %files and %post* for the main package * Add %changelog entry
--- SPECS/utf8proc.spec 2021-09-22 21:24:59.304665646 -0600 +++ /export/home/orion/fedora/utf8proc-epel/utf8proc-epel.spec 2021-09-22 21:32:01.568719918 -0600 @@ -1,11 +1,13 @@ +%global debug_package %{nil} + Summary: Library for processing UTF-8 encoded Unicode strings -Name: utf8proc +Name: utf8proc-epel Version: 2.1.1 Release: 5%{?dist} License: Unicode and MIT Group: System Environment/Libraries URL: http://julialang.org/utf8proc/ -Source: https://github.com/JuliaLang/utf8proc/archive/v%%7Bversion%7D.tar.gz#/%%7Bna... +Source: https://github.com/JuliaLang/utf8proc/archive/v%%7Bversion%7D/utf8proc-%%7Bv... BuildRequires: gcc
%description @@ -21,12 +23,12 @@
This package only contains the C library.
-%package devel +%package -n utf8proc-devel Summary: Header files, libraries and development documentation for %{name} Group: Development/Libraries -Requires: %{name}%{?_isa} = %{version}-%{release} +Requires: utf8proc%{?_isa} >= %{version}-%{release}
-%description devel +%description -n utf8proc-devel Contains header files for developing applications that use the %{name} library.
@@ -35,7 +37,7 @@ strings, unless you want to allocate memory yourself.
%prep -%setup -qn %{name}-%{version} +%setup -qn utf8proc-%{version} # Disable slow tests and tests which require network access sed -i '/-C bench/d;/\ttest.* data/d' Makefile touch data/NormalizationTest.txt data/GraphemeBreakTest.txt touch data/NormalizationTest.txt data/GraphemeBreakTest.txt @@ -50,19 +52,16 @@ %install make install DESTDIR=%{buildroot} prefix=%{_prefix} includedir=%{_includedir} libdir=%{_libdir} rm %{buildroot}%{_libdir}/libutf8proc.a +rm %{buildroot}%{_libdir}/libutf8proc.so.*
-%post -p /sbin/ldconfig -%postun -p /sbin/ldconfig - -%files -%doc LICENSE.md NEWS.md README.md -%{_libdir}/libutf8proc.so.* - -%files devel +%files -n utf8proc-devel %{_includedir}/utf8proc.h %{_libdir}/libutf8proc.so
%changelog +* Wed Sep 22 2021 Orion Poplawski orion@nwra.com - 2.1.1-5 +- EPEL -devel only package + * Mon Aug 05 2019 Lubos Uhliarik luhliari@redhat.com - 2.1.1-5 - Resolves: #1696354 - Ensure modular RPM upgrade path
Comments?
That looks great, and very close to what I've done. I have a couple of variations. I think the biggest is that I set a variable called rhel_name and then change %{name} to %{rhel_name}. It looks like you only had two instances of %{name} but I've had a couple with many instances of it, and this makes it easier. The second is that I usually put a link to the upstream spec file, in comments. I use the CentOS Stream git repo, because it's publicly available. This is mainly for me, cuz I never know where to find them. So, this is at the top of my spec files.
# This spec file is derived from the RHEL8 spec file. # They should be kept in sync over time. # https://git.centos.org/rpms/libpinyin/blob/c8/f/SPECS/libpinyin.spec %global rhel_name libpinyin %global _debugsource_template %{nil}
But, that's just my preferences. I think yours should be fine.
I'm thinking we might want to break this out from a question in the FAQ to it's own page.
Troy
On Wed, Sep 22, 2021 at 8:42 PM Orion Poplawski orion@nwra.com wrote:
On 7/1/21 4:05 PM, 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 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
So, I've decided to try this with utf8proc. I've requested the utf8proc-epel package and now requested an epel8 branch (and will retire the rawhide branch).
These are the changes I have made, does this seem correct? Notes on changes:
- We are not shipping binaries, so need to disable the debug package
- Need to change Name and %{name}
- Need to explicitly name the devel package
- Need to use relative Requires for the main package. Both to allow
RHEL to update and (in this case) to deal with module release tags
- Remove the files installed for the main package
- Remove %files and %post* for the main package
- Add %changelog entry
--- SPECS/utf8proc.spec 2021-09-22 21:24:59.304665646 -0600 +++ /export/home/orion/fedora/utf8proc-epel/utf8proc-epel.spec 2021-09-22 21:32:01.568719918 -0600 @@ -1,11 +1,13 @@ +%global debug_package %{nil}
- Summary: Library for processing UTF-8 encoded Unicode strings
-Name: utf8proc +Name: utf8proc-epel Version: 2.1.1 Release: 5%{?dist} License: Unicode and MIT Group: System Environment/Libraries URL: http://julialang.org/utf8proc/ -Source:
https://github.com/JuliaLang/utf8proc/archive/v%%7Bversion%7D.tar.gz#/%%7Bna... +Source:
https://github.com/JuliaLang/utf8proc/archive/v%%7Bversion%7D/utf8proc-%%7Bv... BuildRequires: gcc
%description @@ -21,12 +23,12 @@
This package only contains the C library.
-%package devel +%package -n utf8proc-devel Summary: Header files, libraries and development documentation for %{name} Group: Development/Libraries -Requires: %{name}%{?_isa} = %{version}-%{release} +Requires: utf8proc%{?_isa} >= %{version}-%{release}
-%description devel +%description -n utf8proc-devel Contains header files for developing applications that use the %{name} library.
@@ -35,7 +37,7 @@ strings, unless you want to allocate memory yourself.
%prep -%setup -qn %{name}-%{version} +%setup -qn utf8proc-%{version} # Disable slow tests and tests which require network access sed -i '/-C bench/d;/\ttest.* data/d' Makefile touch data/NormalizationTest.txt data/GraphemeBreakTest.txt touch data/NormalizationTest.txt data/GraphemeBreakTest.txt @@ -50,19 +52,16 @@ %install make install DESTDIR=%{buildroot} prefix=%{_prefix} includedir=%{_includedir} libdir=%{_libdir} rm %{buildroot}%{_libdir}/libutf8proc.a +rm %{buildroot}%{_libdir}/libutf8proc.so.*
-%post -p /sbin/ldconfig -%postun -p /sbin/ldconfig
-%files -%doc LICENSE.md NEWS.md README.md -%{_libdir}/libutf8proc.so.*
-%files devel +%files -n utf8proc-devel %{_includedir}/utf8proc.h %{_libdir}/libutf8proc.so
%changelog +* Wed Sep 22 2021 Orion Poplawski orion@nwra.com - 2.1.1-5 +- EPEL -devel only package
- Mon Aug 05 2019 Lubos Uhliarik luhliari@redhat.com - 2.1.1-5
- Resolves: #1696354 - Ensure modular RPM upgrade path
Comments?
-- Orion Poplawski he/him/his - surely the least important thing about me Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion@nwra.com Boulder, CO 80301 https://www.nwra.com/
epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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@lists.fedoraproject... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 9/23/21 7:28 AM, Troy Dawson wrote:
That looks great, and very close to what I've done. I have a couple of variations. I think the biggest is that I set a variable called rhel_name and then change %{name} to %{rhel_name}. It looks like you only had two instances of %{name} but I've had a couple with many instances of it, and this makes it easier. The second is that I usually put a link to the upstream spec file, in comments. I use the CentOS Stream git repo, because it's publicly available. This is mainly for me, cuz I never know where to find them. So, this is at the top of my spec files.
# This spec file is derived from the RHEL8 spec file. # They should be kept in sync over time. # https://git.centos.org/rpms/libpinyin/blob/c8/f/SPECS/libpinyin.spec https://git.centos.org/rpms/libpinyin/blob/c8/f/SPECS/libpinyin.spec %global rhel_name libpinyin %global _debugsource_template %{nil}
But, that's just my preferences. I think yours should be fine.
Thanks, good ideas.
I'm thinking we might want to break this out from a question in the FAQ to it's own page.
+1
Troy
On 23. 09. 21 5:41, Orion Poplawski wrote:
-Requires: %{name}%{?_isa} = %{version}-%{release} +Requires: utf8proc%{?_isa} >= %{version}-%{release}
I'd assume that anybody (even you) might need to rebuild this package in EPEL at any time for various reasons and %{release} might be larger than the RHEL package release. This >= requireement will break.
Also, if the RHEL version gets updated to e.g. 2.1.2 (unlikely, but not impossible), the EPEL devel package will still be able to be installed, which is probably undesired.
If you don't need to follow RHEL's release number that much, I suggest to do:
Requires: utf8proc%{?_isa} = %{version}
And if you do, I suggest to do:
%global rhel_release 5 Requires: (utf8proc%{?_isa} = %{version} with utf8proc%{?_isa} >= %{version}-%{rhel_release})
You could even incorporate the RHEL's release to the EPEL's release, if you feel like it:
%global rhel_release 5 %global base_release 1
Release: %{rhel_release}.%{base_release}%{?dist}
Side note: I also suggest to BuildRequire the runtime requirement (sans %{?_isa}) and track the package in Koschei. That way, you can get a notification if the requirement was broken by an RHEL update and the EPEL package needs to be updated as well.
On 9/23/21 9:00 AM, Miro Hrončok wrote:
On 23. 09. 21 5:41, Orion Poplawski wrote:
-Requires: %{name}%{?_isa} = %{version}-%{release} +Requires: utf8proc%{?_isa} >= %{version}-%{release}
I'd assume that anybody (even you) might need to rebuild this package in EPEL at any time for various reasons and %{release} might be larger than the RHEL package release. This >= requireement will break.
Also, if the RHEL version gets updated to e.g. 2.1.2 (unlikely, but not impossible), the EPEL devel package will still be able to be installed, which is probably undesired.
If you don't need to follow RHEL's release number that much, I suggest to do:
Requires: utf8proc%{?_isa} = %{version}
And if you do, I suggest to do:
%global rhel_release 5 Requires: (utf8proc%{?_isa} = %{version} with utf8proc%{?_isa} >= %{version}-%{rhel_release})
You could even incorporate the RHEL's release to the EPEL's release, if you feel like it:
%global rhel_release 5 %global base_release 1
Release: %{rhel_release}.%{base_release}%{?dist}
Side note: I also suggest to BuildRequire the runtime requirement (sans %{?_isa}) and track the package in Koschei. That way, you can get a notification if the requirement was broken by an RHEL update and the EPEL package needs to be updated as well.
Thanks, good ideas!
epel-devel@lists.fedoraproject.org
-
Carl George -
Kevin Fenzi -
Miro Hrončok -
Orion Poplawski -
Sérgio Basto -
Troy Dawson