[EPEL-devel] Re: Proposal for RHEL8 missing -devel packages
On Sun, Dec 13, 2020 at 10:37:49AM -0700, Orion Poplawski wrote: > On 12/11/20 5:04 PM, Miro Hrončok wrote: > > On 12/12/20 12:12 AM, Troy Dawson wrote: > > > There is also a problem if a missing package has been specifically > > > blocked by a module. I think libuv-devel is this way. > > > > If that happens, wouldn't it be blocked in both scenarios > > (module+grobisplitter+tagging and devel-only-component)? Or would > > grobisplitter put them in an additional repo with module_hotfixes=yes? > > > > If that's the case, it might be possible to create a separate repo with > > such packages only and manually tag them there. E.g. after a build I'd > > do `koji tag epel8-buildroot-module-hotfixes foo-devel-1.6-5.el8` and > > the epel8-buildroot-module-hotfixes repo would be available from EPEL 8 > > Koji/mock builds with module_hotfixes=yes. Yes, unlike the rest of this > > proposal, it requires some work (on infra to set up this extra repo and > > on packagers to remember to do the tagging, but that still sounds like > > less work than the grobisplitter proposal for both groups). > > Is there any easy way to tell if a package is explicitly blocked vs just not > being present. You can ask koji: koji list-pkgs --show-blocked --package whatever and it will tell you what tags it's blocked in with [BLOCKED] 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
[EPEL-devel] Re: Proposal for RHEL8 missing -devel packages
On Tue, Dec 15, 2020 at 5:06 AM Andrew C Aitchison
wrote:
>
> On Tue, 15 Dec 2020, Miro Hrončok wrote:
>
> > On 12/13/20 7:52 PM, Andrew C Aitchison wrote:
> >>
> >> On Sun, 13 Dec 2020, Miro Hrončok wrote:
> >>
> >>> Also, since you might want to bump the release independently in EPEL (e.g.
> >>> if we discover something was wrong in the way we have packaged this), I
> >>> recommend doing:
> >>>
> >>> %global rhelrelease 10
> >>> %global baserelease 1
> >>> Release: %{rhelrelease}.%{baserelease}%{?dist}
> >>> ...
> >>> Requires: qpdf-libs%{?_isa} = %{version}-%{rhelrelease}%{?dist}
> >>>
> >>> (Assuming qpdf has regular %{dist} and not some modularity artificial
> >>> value.)
> >>>
> >>> Note that I've named the EPEL part of the release "baserelease", so
> >>> rpmdev-bumpspec does the right thing.
> >>
> >> If rhelrelease updates to 10.1 which will win ?
> >> ... and if we have already bumped baserelease to 2 ?
> >>
> >> rhelreleasename
> >> baserelease
> >> 102qpdf-devel-10.2.epel.rpm
> >> 10.1qpdf-devel-10.1.rhel.rpm
> >>
> >> Which will win ?
> >
> > Right. Can we use ^ in EL8 to separate the RHEL and EPEL parts?
>
> "^" sorts after digits (at least in ASCII and Basic Latin), so
> can anyone check whether
> qpdf-devel-10^2.epel.rpm
> will trump
> qpdf-devel-100.1.rhel.rpm
> or
> qpdf-devel-10.3.rhel.rpm
> ?
> My recollection is that there have been several different
> implementations of parsers for version-release checks with different
> twisty paths for splitting sub-components.
> My last RedHat based system is SL6 (sorry I moved to Ubuntu to match
> work) so I couldn't do a reliable test myself.
>
Sorry I'm late in replying, but why don't you use
Release: %{rhelrelease}%{?dist}.%{baserelease}
rhelrelease baserelease name
10 2 qpdf-devel-10.el8.2.rpm
10.1 2qpdf-devel-10.1.el8.2.rpm
$ rpmdev-vercmp 10.el8.2 10.1.el8.2
10.el8.2 < 10.1.el8.2
Troy
___
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
[EPEL-devel] Re: Proposal for RHEL8 missing -devel packages
On Tue, 15 Dec 2020, Miro Hrončok wrote:
On 12/13/20 7:52 PM, Andrew C Aitchison wrote:
On Sun, 13 Dec 2020, Miro Hrončok wrote:
Also, since you might want to bump the release independently in EPEL (e.g.
if we discover something was wrong in the way we have packaged this), I
recommend doing:
%global rhelrelease 10
%global baserelease 1
Release: %{rhelrelease}.%{baserelease}%{?dist}
...
Requires: qpdf-libs%{?_isa} = %{version}-%{rhelrelease}%{?dist}
(Assuming qpdf has regular %{dist} and not some modularity artificial
value.)
Note that I've named the EPEL part of the release "baserelease", so
rpmdev-bumpspec does the right thing.
If rhelrelease updates to 10.1 which will win ?
... and if we have already bumped baserelease to 2 ?
rhelrelease name
baserelease
10 2 qpdf-devel-10.2.epel.rpm
10.1 qpdf-devel-10.1.rhel.rpm
Which will win ?
Right. Can we use ^ in EL8 to separate the RHEL and EPEL parts?
"^" sorts after digits (at least in ASCII and Basic Latin), so
can anyone check whether
qpdf-devel-10^2.epel.rpm
will trump
qpdf-devel-100.1.rhel.rpm
or
qpdf-devel-10.3.rhel.rpm
?
My recollection is that there have been several different
implementations of parsers for version-release checks with different
twisty paths for splitting sub-components.
My last RedHat based system is SL6 (sorry I moved to Ubuntu to match
work) so I couldn't do a reliable test myself.
--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk___
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
[EPEL-devel] Re: Proposal for RHEL8 missing -devel packages
On 12/13/20 7:52 PM, Andrew C Aitchison wrote:
On Sun, 13 Dec 2020, Miro Hrončok wrote:
Also, since you might want to bump the release independently in EPEL (e.g. if
we discover something was wrong in the way we have packaged this), I recommend
doing:
%global rhelrelease 10
%global baserelease 1
Release: %{rhelrelease}.%{baserelease}%{?dist}
...
Requires: qpdf-libs%{?_isa} = %{version}-%{rhelrelease}%{?dist}
(Assuming qpdf has regular %{dist} and not some modularity artificial value.)
Note that I've named the EPEL part of the release "baserelease", so
rpmdev-bumpspec does the right thing.
If rhelrelease updates to 10.1 which will win ?
... and if we have already bumped baserelease to 2 ?
rhelrelease name
baserelease
10 2 qpdf-devel-10.2.epel.rpm
10.1 qpdf-devel-10.1.rhel.rpm
Which will win ?
Right. Can we use ^ in EL8 to separate the RHEL and EPEL parts?
--
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
[EPEL-devel] Re: Proposal for RHEL8 missing -devel packages
On 12/13/20 7:21 PM, Stephen John Smoogen wrote:
Don't forget to move the following metadata to the main package:
Summary: Development files for QPDF library
Requires: qpdf-libs%{?_isa} = %{version}-%{release}
Do you mean the main package as qpdf ? We don't control that package.
No. I mean the main qpdf-devel package of the qpdf-devel component.
So when I've said "move" I should have said "copy" instead, sorry.
--
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
[EPEL-devel] Re: Proposal for RHEL8 missing -devel packages
On Sun, 13 Dec 2020, Miro Hrončok wrote:
Also, since you might want to bump the release independently in EPEL (e.g. if
we discover something was wrong in the way we have packaged this), I
recommend doing:
%global rhelrelease 10
%global baserelease 1
Release: %{rhelrelease}.%{baserelease}%{?dist}
...
Requires: qpdf-libs%{?_isa} = %{version}-%{rhelrelease}%{?dist}
(Assuming qpdf has regular %{dist} and not some modularity artificial value.)
Note that I've named the EPEL part of the release "baserelease", so
rpmdev-bumpspec does the right thing.
If rhelrelease updates to 10.1 which will win ?
... and if we have already bumped baserelease to 2 ?
rhelrelease name
baserelease
10 2 qpdf-devel-10.2.epel.rpm
10.1qpdf-devel-10.1.rhel.rpm
Which will win ?
--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk___
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
[EPEL-devel] Re: Proposal for RHEL8 missing -devel packages
On Sun, 13 Dec 2020 at 13:17, Miro Hrončok wrote:
> On 12/13/20 7:03 PM, Orion Poplawski wrote:
> > On 12/13/20 10:37 AM, Orion Poplawski wrote:
> >> On 12/11/20 5:04 PM, Miro Hrončok wrote:
> >>> On 12/12/20 12:12 AM, Troy Dawson wrote:
>
> > Seem reasonable? I was able to install the resulting qpdf-devel fine.
>
> Don't forget to move the following metadata to the main package:
>
>Summary: Development files for QPDF library
>Requires: qpdf-libs%{?_isa} = %{version}-%{release}
>
>
Do you mean the main package as qpdf ? We don't control that package.
> Also, since you might want to bump the release independently in EPEL (e.g.
> if we
> discover something was wrong in the way we have packaged this), I
> recommend doing:
>
>%global rhelrelease 10
>%global baserelease 1
>Release: %{rhelrelease}.%{baserelease}%{?dist}
>...
>Requires: qpdf-libs%{?_isa} = %{version}-%{rhelrelease}%{?dist}
>
> (Assuming qpdf has regular %{dist} and not some modularity artificial
> value.)
>
> Note that I've named the EPEL part of the release "baserelease", so
> rpmdev-bumpspec does the right thing.
>
>
That makes sense.
> --
> 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
>
--
Stephen J Smoogen.
___
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
[EPEL-devel] Re: Proposal for RHEL8 missing -devel packages
On 12/13/20 7:03 PM, Orion Poplawski wrote:
On 12/13/20 10:37 AM, Orion Poplawski wrote:
On 12/11/20 5:04 PM, Miro Hrončok wrote:
On 12/12/20 12:12 AM, Troy Dawson wrote:
We discussed this in the EPEL Steering Committee this week, and your
way has alot less "mess with the server and modules" work.
It would probably get us up to 75% of the missing packages.
If people who have been waiting for packages want to give this a try
and show what they did for others to follow, that would be great.
I'll probrubly do it for some of the packages I want. And see what
type of scripts, patches, and other things are needed.
Let me know if you have a devel package in mind and I can give it a try.
Can we just jump in and try this out? I'd like to get qpdf-devel available.
Here's what I have for a diff so far for qpdf-devel:
--- /export/home/orion/centos/qpdf/SPECS/qpdf.spec 2020-12-13
10:39:15.439288925 -0700
+++ qpdf-devel.spec 2020-12-13 10:52:37.567863216 -0700
@@ -1,5 +1,7 @@
+%global debug_package %{nil}
+
Summary: Command-line tools and library for transforming PDF files
-Name: qpdf
+Name: qpdf-devel
Version: 7.1.1
Release: 10%{?dist}
# MIT: e.g. libqpdf/sha2.c
@@ -72,7 +74,7 @@
QPDF Manual
%prep
-%setup -q
+%setup -q -n qpdf-%{version}
# fix 'complete manual location' note in man pages
%patch0 -p1 -b .doc
@@ -99,35 +101,17 @@
make install DESTDIR=%{buildroot}
rm -f %{buildroot}%{_libdir}/libqpdf.la
+rm -rf %{buildroot}/usr/{bin,share} %{buildroot}%{_libdir}/*.so.*
%check
make check
-%post libs -p /sbin/ldconfig
-
-%postun libs -p /sbin/ldconfig
-
%files
-%{_bindir}/fix-qdf
-%{_bindir}/qpdf
-%{_bindir}/zlib-flate
-%{_mandir}/man1/*
-
-%files libs
-%doc README.md TODO ChangeLog
-%license Artistic-2.0
-%{_libdir}/libqpdf*.so.*
-
-%files devel
%doc examples/*.cc examples/*.c
%{_includedir}/*
%{_libdir}/libqpdf*.so
%{_libdir}/pkgconfig/libqpdf.pc
-%files doc
-%{_pkgdocdir}
-
-
%changelog
Seem reasonable? I was able to install the resulting qpdf-devel fine.
Don't forget to move the following metadata to the main package:
Summary: Development files for QPDF library
Requires: qpdf-libs%{?_isa} = %{version}-%{release}
Also, since you might want to bump the release independently in EPEL (e.g. if we
discover something was wrong in the way we have packaged this), I recommend doing:
%global rhelrelease 10
%global baserelease 1
Release: %{rhelrelease}.%{baserelease}%{?dist}
...
Requires: qpdf-libs%{?_isa} = %{version}-%{rhelrelease}%{?dist}
(Assuming qpdf has regular %{dist} and not some modularity artificial value.)
Note that I've named the EPEL part of the release "baserelease", so
rpmdev-bumpspec does the right thing.
--
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
[EPEL-devel] Re: Proposal for RHEL8 missing -devel packages
On 12/13/20 10:37 AM, Orion Poplawski wrote:
On 12/11/20 5:04 PM, Miro Hrončok wrote:
On 12/12/20 12:12 AM, Troy Dawson wrote:
We discussed this in the EPEL Steering Committee this week, and your
way has alot less "mess with the server and modules" work.
It would probably get us up to 75% of the missing packages.
If people who have been waiting for packages want to give this a try
and show what they did for others to follow, that would be great.
I'll probrubly do it for some of the packages I want. And see what
type of scripts, patches, and other things are needed.
Let me know if you have a devel package in mind and I can give it a try.
Can we just jump in and try this out? I'd like to get qpdf-devel
available.
Here's what I have for a diff so far for qpdf-devel:
--- /export/home/orion/centos/qpdf/SPECS/qpdf.spec 2020-12-13
10:39:15.439288925 -0700
+++ qpdf-devel.spec 2020-12-13 10:52:37.567863216 -0700
@@ -1,5 +1,7 @@
+%global debug_package %{nil}
+
Summary: Command-line tools and library for transforming PDF files
-Name:qpdf
+Name:qpdf-devel
Version: 7.1.1
Release: 10%{?dist}
# MIT: e.g. libqpdf/sha2.c
@@ -72,7 +74,7 @@
QPDF Manual
%prep
-%setup -q
+%setup -q -n qpdf-%{version}
# fix 'complete manual location' note in man pages
%patch0 -p1 -b .doc
@@ -99,35 +101,17 @@
make install DESTDIR=%{buildroot}
rm -f %{buildroot}%{_libdir}/libqpdf.la
+rm -rf %{buildroot}/usr/{bin,share} %{buildroot}%{_libdir}/*.so.*
%check
make check
-%post libs -p /sbin/ldconfig
-
-%postun libs -p /sbin/ldconfig
-
%files
-%{_bindir}/fix-qdf
-%{_bindir}/qpdf
-%{_bindir}/zlib-flate
-%{_mandir}/man1/*
-
-%files libs
-%doc README.md TODO ChangeLog
-%license Artistic-2.0
-%{_libdir}/libqpdf*.so.*
-
-%files devel
%doc examples/*.cc examples/*.c
%{_includedir}/*
%{_libdir}/libqpdf*.so
%{_libdir}/pkgconfig/libqpdf.pc
-%files doc
-%{_pkgdocdir}
-
-
%changelog
Seem reasonable? I was able to install the resulting qpdf-devel fine.
--
Orion Poplawski
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
[EPEL-devel] Re: Proposal for RHEL8 missing -devel packages
On Sun, 13 Dec 2020 at 12:38, Orion Poplawski wrote: > On 12/11/20 5:04 PM, Miro Hrončok wrote: > > On 12/12/20 12:12 AM, Troy Dawson wrote: > >> There is also a problem if a missing package has been specifically > >> blocked by a module. I think libuv-devel is this way. > > > > If that happens, wouldn't it be blocked in both scenarios > > (module+grobisplitter+tagging and devel-only-component)? Or would > > grobisplitter put them in an additional repo with module_hotfixes=yes? > > > > If that's the case, it might be possible to create a separate repo with > > such packages only and manually tag them there. E.g. after a build I'd > > do `koji tag epel8-buildroot-module-hotfixes foo-devel-1.6-5.el8` and > > the epel8-buildroot-module-hotfixes repo would be available from EPEL 8 > > Koji/mock builds with module_hotfixes=yes. Yes, unlike the rest of this > > proposal, it requires some work (on infra to set up this extra repo and > > on packagers to remember to do the tagging, but that still sounds like > > less work than the grobisplitter proposal for both groups). > > Is there any easy way to tell if a package is explicitly blocked vs just > not being present. > > I thought there was one way by looking at the modules.yaml file and parse through the yaml for artifacts and filter.. however when I was doing that for the EPEL-8 bringup in 2019.. it was not always accurate. > >> We discussed this in the EPEL Steering Committee this week, and your > >> way has alot less "mess with the server and modules" work. > >> It would probably get us up to 75% of the missing packages. > >> > >> If people who have been waiting for packages want to give this a try > >> and show what they did for others to follow, that would be great. > >> I'll probrubly do it for some of the packages I want. And see what > >> type of scripts, patches, and other things are needed. > > > > Let me know if you have a devel package in mind and I can give it a try. > > Can we just jump in and try this out? I'd like to get qpdf-devel > available. If so, I guess I would do: > > fedpkg request-repo --exception qpdf-devel > > right? > > I don't know so I can't answer this. > -- > Orion Poplawski > 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/ > > ___ > 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 > -- Stephen J Smoogen. ___ 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
[EPEL-devel] Re: Proposal for RHEL8 missing -devel packages
On 12/11/20 5:04 PM, Miro Hrončok wrote: On 12/12/20 12:12 AM, Troy Dawson wrote: There is also a problem if a missing package has been specifically blocked by a module. I think libuv-devel is this way. If that happens, wouldn't it be blocked in both scenarios (module+grobisplitter+tagging and devel-only-component)? Or would grobisplitter put them in an additional repo with module_hotfixes=yes? If that's the case, it might be possible to create a separate repo with such packages only and manually tag them there. E.g. after a build I'd do `koji tag epel8-buildroot-module-hotfixes foo-devel-1.6-5.el8` and the epel8-buildroot-module-hotfixes repo would be available from EPEL 8 Koji/mock builds with module_hotfixes=yes. Yes, unlike the rest of this proposal, it requires some work (on infra to set up this extra repo and on packagers to remember to do the tagging, but that still sounds like less work than the grobisplitter proposal for both groups). Is there any easy way to tell if a package is explicitly blocked vs just not being present. We discussed this in the EPEL Steering Committee this week, and your way has alot less "mess with the server and modules" work. It would probably get us up to 75% of the missing packages. If people who have been waiting for packages want to give this a try and show what they did for others to follow, that would be great. I'll probrubly do it for some of the packages I want. And see what type of scripts, patches, and other things are needed. Let me know if you have a devel package in mind and I can give it a try. Can we just jump in and try this out? I'd like to get qpdf-devel available. If so, I guess I would do: fedpkg request-repo --exception qpdf-devel right? -- Orion Poplawski 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
[EPEL-devel] Re: Proposal for RHEL8 missing -devel packages
On 12/12/20 12:12 AM, Troy Dawson wrote: At the end a package called qgpgme-devel will be built in EPEL and available in the EPEL buildroot despite the fact that there is a qgpgme-devel package in RHEL buildroot. Since the only reason we don't allow this already is policy, why don't we amend the policy instead to allow adding qgpgme-devel to EPEL if it's in RHEL buildroot? No modules, no grobisplitter, just plain simple spec file that only produces qgpgme-devel (and deletes or %excludes the rest). IMHO that's something EPEL packagers are more likely to understand (and hence are more OK to maintain). They already can if they want. There is no policy preventing creating a srpm with a different name that creates a binary that isn't in the RHEL release. I understood the policy here: https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy ...as "thou shalt not package in EPEL what's already in RHEL" and codeready-builder-for-rhel-8 seems to "be in RHEL". If the problems are only with packages that are not even in CRB, but filtered out by modular "features", possibly such packages are indeed not disallowed (not sure, maybe the policy could explicitly say that they are allowed?). If fact, just the opposite, there is a special provision for that in the packaging review guidelines https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process see bullet 3. Oh, my confusion apparently lies in "does not exist (or is not shipped) in RHEL" -- do I now understand this correctly that if a subpackage (e.g. qgpgme-devel) exists in RHEL but is not shipped, it is explicitly allowed to package it in EPEL under a new component name (e.g. qgpgme-devel) (and as a bonus, does not even need a package review)? If so, should we document this also in the EPEL policy? I believe what most people are worried about is keeping it in sync with the RHEL release. In what way does the modularity solution make this easier? The -devel subpackage tagged into the epel8 buildroot needs to be in sync with the runtime package from RHEL in either case, doesn't it? As for the fragility of this: I maintain an EPEL 7 package that needs to be kept in sync with RHEL 7 (python3-rpm) and A) RHEL doesn't release that often, B) when it goes out of sync, things break and I notice, so I can fix it. (Obviously in EPEL Next, this will be more challenging because (A) is no longer true.) There is also a problem if a missing package has been specifically blocked by a module. I think libuv-devel is this way. If that happens, wouldn't it be blocked in both scenarios (module+grobisplitter+tagging and devel-only-component)? Or would grobisplitter put them in an additional repo with module_hotfixes=yes? If that's the case, it might be possible to create a separate repo with such packages only and manually tag them there. E.g. after a build I'd do `koji tag epel8-buildroot-module-hotfixes foo-devel-1.6-5.el8` and the epel8-buildroot-module-hotfixes repo would be available from EPEL 8 Koji/mock builds with module_hotfixes=yes. Yes, unlike the rest of this proposal, it requires some work (on infra to set up this extra repo and on packagers to remember to do the tagging, but that still sounds like less work than the grobisplitter proposal for both groups). We discussed this in the EPEL Steering Committee this week, and your way has alot less "mess with the server and modules" work. It would probably get us up to 75% of the missing packages. If people who have been waiting for packages want to give this a try and show what they did for others to follow, that would be great. I'll probrubly do it for some of the packages I want. And see what type of scripts, patches, and other things are needed. Let me know if you have a devel package in mind and I can give it a try. Thanks for the feedback. It was very helpful. Thanks for trying to solve this problem. -- 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
[EPEL-devel] Re: Proposal for RHEL8 missing -devel packages
On Fri, Dec 11, 2020 at 1:44 PM Miro Hrončok wrote:
>
> On 12/11/20 7:42 PM, Troy Dawson wrote:
> > Our current solution for the missing RHEL8 devel packages is going away.
> > And let's be honest, it was only about 50% successful. We needed
> > something else anyway.
> >
> > Here is my proposal for a new solution.
> > Be warned, this proposal has words like module, and grobisplitter.
> > But I think it will turn out good in the end.
> > It's just a proposal. Some things might be impossible, some might
> > just be hard. But, in my head it works.
> >
> > Example: qgpgme-devel is missing. It is a subpackage of gpgme
> > 1 - Create a epel8 module called qgpgme-devel(A)
> > 1a - Everything is blocked by the module, except the package qgpgme-devel
> > 2 - In the fedora dist-git repo for gpgme, create a branch called
> > epel8-missing-devel(B)
> > 2a - If other packages are needed to build gpgme in EPEL8, create the
> > same named branch in their dist-git repos.
> > 3 - Sync the centos-git branches to the fedora epel8-missing-devel
> > branches, including sources to the fedora lookaside. (C)
> > 4 - Change %{dist} in the spec files to .el8
> > 5 - Build the module
> > 6 - Process the module through the usual bodhi process, and thus EPEL
> > end users can use qgpgme-devel, as an EPEL module.
> > 7 - Configure grobisplitter so that the contents of the module (which
> > is just qgpgme-devel) can be squashed and used as a normal rpm in
> > epel8 buildroot.
> > 8 - Via a script, check centos-git branch of gpgme to see if it has
> > been updated. If it has been updated, do steps 3 through 6.
> >
> > Notes:
> > (A) - Do not name the module the same as the original source package.
> > This will confuse users of the original package.
> > (B) - This branch name is debatable, but it should be consistent so
> > updates can be scripted.
> > (C) - Once the centos and fedora dist-git branches are on the same
> > place, this will be easier, but is still needed.
> > (D) - Yes, that's right. Hard code %{dist}
>
> At the end a package called qgpgme-devel will be built in EPEL and available
> in
> the EPEL buildroot despite the fact that there is a qgpgme-devel package in
> RHEL
> buildroot.
>
> Since the only reason we don't allow this already is policy, why don't we
> amend
> the policy instead to allow adding qgpgme-devel to EPEL if it's in RHEL
> buildroot? No modules, no grobisplitter, just plain simple spec file that only
> produces qgpgme-devel (and deletes or %excludes the rest). IMHO that's
> something
> EPEL packagers are more likely to understand (and hence are more OK to
> maintain).
>
They already can if they want.
There is no policy preventing creating a srpm with a different name
that creates a binary that isn't in the RHEL release.
If fact, just the opposite, there is a special provision for that in
the packaging review guidelines
https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process
see bullet 3.
I believe what most people are worried about is keeping it in sync
with the RHEL release.
There is also a problem if a missing package has been specifically
blocked by a module. I think libuv-devel is this way.
We discussed this in the EPEL Steering Committee this week, and your
way has alot less "mess with the server and modules" work.
It would probably get us up to 75% of the missing packages.
If people who have been waiting for packages want to give this a try
and show what they did for others to follow, that would be great.
I'll probrubly do it for some of the packages I want. And see what
type of scripts, patches, and other things are needed.
Thanks for the feedback. It was very helpful.
Troy
___
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
[EPEL-devel] Re: Proposal for RHEL8 missing -devel packages
On 12/11/20 7:42 PM, Troy Dawson wrote:
Our current solution for the missing RHEL8 devel packages is going away.
And let's be honest, it was only about 50% successful. We needed
something else anyway.
Here is my proposal for a new solution.
Be warned, this proposal has words like module, and grobisplitter.
But I think it will turn out good in the end.
It's just a proposal. Some things might be impossible, some might
just be hard. But, in my head it works.
Example: qgpgme-devel is missing. It is a subpackage of gpgme
1 - Create a epel8 module called qgpgme-devel(A)
1a - Everything is blocked by the module, except the package qgpgme-devel
2 - In the fedora dist-git repo for gpgme, create a branch called
epel8-missing-devel(B)
2a - If other packages are needed to build gpgme in EPEL8, create the
same named branch in their dist-git repos.
3 - Sync the centos-git branches to the fedora epel8-missing-devel
branches, including sources to the fedora lookaside. (C)
4 - Change %{dist} in the spec files to .el8
5 - Build the module
6 - Process the module through the usual bodhi process, and thus EPEL
end users can use qgpgme-devel, as an EPEL module.
7 - Configure grobisplitter so that the contents of the module (which
is just qgpgme-devel) can be squashed and used as a normal rpm in
epel8 buildroot.
8 - Via a script, check centos-git branch of gpgme to see if it has
been updated. If it has been updated, do steps 3 through 6.
Notes:
(A) - Do not name the module the same as the original source package.
This will confuse users of the original package.
(B) - This branch name is debatable, but it should be consistent so
updates can be scripted.
(C) - Once the centos and fedora dist-git branches are on the same
place, this will be easier, but is still needed.
(D) - Yes, that's right. Hard code %{dist}
At the end a package called qgpgme-devel will be built in EPEL and available in
the EPEL buildroot despite the fact that there is a qgpgme-devel package in RHEL
buildroot.
Since the only reason we don't allow this already is policy, why don't we amend
the policy instead to allow adding qgpgme-devel to EPEL if it's in RHEL
buildroot? No modules, no grobisplitter, just plain simple spec file that only
produces qgpgme-devel (and deletes or %excludes the rest). IMHO that's something
EPEL packagers are more likely to understand (and hence are more OK to maintain).
--
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
