[EPEL-devel] Re: proposed recommendation - missing devel packages

2021-09-23 Thread Orion Poplawski 

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!

--
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   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic Signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: proposed recommendation - missing devel packages

2021-09-23 Thread Orion Poplawski 

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 


%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



--
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   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic Signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: proposed recommendation - missing devel packages

2021-09-23 Thread Miro Hrončok 

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.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: proposed recommendation - missing devel packages

2021-09-23 Thread Troy Dawson 
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  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  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 -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 -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%{version}.tar.gz#/%{name}-v%{version}.tar.gz
> +Source:
>
> https://github.com/JuliaLang/utf8proc/archive/v%{version}/utf8proc-%{version}.tar.gz
>   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/Norma

[EPEL-devel] Re: proposed recommendation - missing devel packages

2021-09-22 Thread Orion Poplawski 

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  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 -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 -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%{version}.tar.gz#/%{name}-v%{version}.tar.gz
+Source: 
https://github.com/JuliaLang/utf8proc/archive/v%{version}/utf8proc-%{version}.tar.gz

 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  - 2.1.1-5
+- EPEL -devel only package
+
 * Mon Aug 05 2019 Lubos Uhliarik  - 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   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic Signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedorapr

[EPEL-devel] Re: proposed recommendation - missing devel packages

2021-07-02 Thread Carl George 
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  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 -epel
>
> --- It cannot be named  (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 -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-le...@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.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Carl George
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: proposed recommendation - missing devel packages

2021-07-01 Thread Kevin Fenzi 
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 -epel

--- It cannot be named  (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 -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


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure