1:13 p.m.
I'm looking for some clarification on the naming requirements for SRPMs.
In the EPEL 7 in Python 3 Plan Draft [1], it specifies that SRPM names
can't conflict with RHEL SRPM names, but in the Limited Arch Packages
[2]section of EPEL: Packaging, it seems to imply the SRPM name would be the
same, but the release number would be pretended with "0.".
Could someone please clarify?
If, in fact, the name can be the same, it will make it much easier to
provide Python 3 packages for EPEL since a separate package would not be
required in the Fedora Package DB.
Avram
[1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3#
Packaging_Parallel_python3X_stacks
[2] https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages
1:28 p.m.
On 13 September 2016 at 14:13, Avram Lubkin <aviso(a)rockhopper.net> wrote:
I'm looking for some clarification on the naming requirements for
SRPMs.
In the EPEL 7 in Python 3 Plan Draft [1], it specifies that SRPM names can't
conflict with RHEL SRPM names, but in the Limited Arch Packages [2]section
of EPEL: Packaging, it seems to imply the SRPM name would be the same, but
the release number would be pretended with "0.".
Limited arch packages are ones where you are building something for
say ppc or aarch64 which has a RHEL package already in x86_64 but no
corresponding RHEL ppc or x86_64 one. The reason to put a 0. in front
is that sometimes RHEL does offer such packages later in a release
cycle and we want that version to overwrite anything we built to
satisfy a dependency. [Also if CentOS builds all the packages for
their port of EL-X to PPC or aarch64 we do not conflict with their
packages.]
This is only meant for that case.
Could someone please clarify?
If, in fact, the name can be the same, it will make it much easier to
provide Python 3 packages for EPEL since a separate package would not be
required in the Fedora Package DB.
The reasoning for needing a python3-foobaz is that we don't replace
the python2 version of foobaz with a package which does not work at
all with the python2 installed and possibly breaks an existing app.
My personal take is that all python3 apps should be called python3 in
their names and all python2 apps should have been called python2 as
every time python does these major updates we end up with years of
maintaining this split brain damage which lasts longer than the
language version exists.
Avram
[1]
https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3#Packaging_Paral...
[2] https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages
_______________________________________________
epel-devel mailing list
epel-devel(a)lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraprojec...
--
Stephen J Smoogen.
3:39 p.m.
On 09/13/2016 01:28 PM, Stephen John Smoogen wrote:
On 13 September 2016 at 14:13, Avram Lubkin
<aviso(a)rockhopper.net> wrote:
> I'm looking for some clarification on the naming requirements for SRPMs.
>
> In the EPEL 7 in Python 3 Plan Draft [1], it specifies that SRPM names can't
> conflict with RHEL SRPM names, but in the Limited Arch Packages [2]section
> of EPEL: Packaging, it seems to imply the SRPM name would be the same, but
> the release number would be pretended with "0.".
>
Limited arch packages are ones where you are building something for
say ppc or aarch64 which has a RHEL package already in x86_64 but no
corresponding RHEL ppc or x86_64 one. The reason to put a 0. in front
is that sometimes RHEL does offer such packages later in a release
cycle and we want that version to overwrite anything we built to
satisfy a dependency. [Also if CentOS builds all the packages for
their port of EL-X to PPC or aarch64 we do not conflict with their
packages.]
This is only meant for that case.
> Could someone please clarify?
>
> If, in fact, the name can be the same, it will make it much easier to
> provide Python 3 packages for EPEL since a separate package would not be
> required in the Fedora Package DB.
>
The reasoning for needing a python3-foobaz is that we don't replace
the python2 version of foobaz with a package which does not work at
all with the python2 installed and possibly breaks an existing app.
My personal take is that all python3 apps should be called python3 in
their names and all python2 apps should have been called python2 as
every time python does these major updates we end up with years of
maintaining this split brain damage which lasts longer than the
language version exists.
I'm in the process of working through this for a few python bits for
EPEL7. While I generally agree, it's problematic at times because the
fedora sources provide a sane split for this, while the EL sources do
not. This occasionally means creating a new package just for EPEL rather
than simply branching the fedora tree.
--
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
4:14 p.m.
On Tue, Sep 13, 2016 at 2:28 PM, Stephen John Smoogen <smooge(a)gmail.com>
wrote:
The reasoning for needing a python3-foobaz is that we don't replace
the python2 version of foobaz with a package which does not work at
all with the python2 installed and possibly breaks an existing app.
You seem to be talking about RPM names and not SRPM names. By convention,
any Python 3 package for EPEL7 would actually be python34-package. The
point of this thread is to discuss SRPM names and if python34-package can
be built from a SPRM package named python-package like in Fedora. Since
python2 and python3 packages are generally built from the same source and
spec, the SRPM and Fedora Git repo are usually not versioned. The problem
is when a python2 package exists in RHEL, but we want to supply a python34
package. The draft guidelines (which are the only ones we have) say this is
a conflict, but it seems that is not stated anywhere in the EPEL
guidelines. The main problem this creates is very few python34 packages get
created because people don't want to maintain multiple repos for the same
thing.
As far as the limited arch packages, I bring that up because it seems from
the guidelines their SRPM name would be the same as the one in RHEL. If
that is acceptable there, it likely should be for python packages.
Avram
4:25 p.m.
On Tue, Sep 13, 2016 at 5:14 PM, Avram Lubkin <aviso(a)rockhopper.net> wrote:
On Tue, Sep 13, 2016 at 2:28 PM, Stephen John Smoogen
<smooge(a)gmail.com>
wrote:
>
>
> The reasoning for needing a python3-foobaz is that we don't replace
> the python2 version of foobaz with a package which does not work at
> all with the python2 installed and possibly breaks an existing app.
You seem to be talking about RPM names and not SRPM names. By convention,
any Python 3 package for EPEL7 would actually be python34-package. The point
of this thread is to discuss SRPM names and if python34-package can be built
from a SPRM package named python-package like in Fedora. Since python2 and
python3 packages are generally built from the same source and spec, the SRPM
and Fedora Git repo are usually not versioned. The problem is when a python2
package exists in RHEL, but we want to supply a python34 package. The draft
guidelines (which are the only ones we have) say this is a conflict, but it
seems that is not stated anywhere in the EPEL guidelines. The main problem
this creates is very few python34 packages get created because people don't
want to maintain multiple repos for the same thing.
As far as the limited arch packages, I bring that up because it seems from
the guidelines their SRPM name would be the same as the one in RHEL. If that
is acceptable there, it likely should be for python packages.
In general, I do not understand why we need to have brand new
"python3-*" SRPMs for these things. It makes far more sense to just
add a conditional for building the Python2 version so that it doesn't
get built for EPEL in places where it overlaps with an existing
package from the base. The SRPM names should be irrelevant and reusing
the SRPMs from Fedora makes tracking things much simpler.
--
真実はいつも一つ！/ Always, there's only one truth!
7:05 p.m.
On 13 September 2016 at 17:14, Avram Lubkin <aviso(a)rockhopper.net> wrote:
On Tue, Sep 13, 2016 at 2:28 PM, Stephen John Smoogen
<smooge(a)gmail.com>
wrote:
>
>
> The reasoning for needing a python3-foobaz is that we don't replace
> the python2 version of foobaz with a package which does not work at
> all with the python2 installed and possibly breaks an existing app.
You seem to be talking about RPM names and not SRPM names. By convention,
any Python 3 package for EPEL7 would actually be python34-package. The point
of this thread is to discuss SRPM names and if python34-package can be built
from a SPRM package named python-package like in Fedora. Since python2 and
python3 packages are generally built from the same source and spec, the SRPM
and Fedora Git repo are usually not versioned. The problem is when a python2
package exists in RHEL, but we want to supply a python34 package. The draft
guidelines (which are the only ones we have) say this is a conflict, but it
seems that is not stated anywhere in the EPEL guidelines. The main problem
this creates is very few python34 packages get created because people don't
want to maintain multiple repos for the same thing.
You are right, I was not correctly thinking when I wrote that. Part of
my brain was assuming that you would be pulling in newer versions of
python-foobaz since usually the stuff in RHEL is considered old and
decrepit for people wanting python3. The one issue I can see with
using the python-foobaz-1.3-0.1.epel.src.rpm is that it is going to
cause problems for CentOS builders/users in that the spec file for the
CentOS package is going to conflict with the EPEL one.. but that is
just a concern that I would want the CentOS members to talk about.
As far as the limited arch packages, I bring that up because it seems
from
the guidelines their SRPM name would be the same as the one in RHEL. If that
is acceptable there, it likely should be for python packages.
Avram
_______________________________________________
epel-devel mailing list
epel-devel(a)lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraprojec...
--
Stephen J Smoogen.
4:26 p.m.
On Tue, 13 Sep 2016 14:13:44 -0400
Avram Lubkin <aviso(a)rockhopper.net> wrote:
I'm looking for some clarification on the naming requirements
for
SRPMs.
In the EPEL 7 in Python 3 Plan Draft [1], it specifies that SRPM names
can't conflict with RHEL SRPM names, but in the Limited Arch Packages
[2]section of EPEL: Packaging, it seems to imply the SRPM name would
be the same, but the release number would be pretended with "0.".
Could someone please clarify?
If, in fact, the name can be the same, it will make it much easier to
provide Python 3 packages for EPEL since a separate package would not
be required in the Fedora Package DB.
So, here's the thing (at least as I understand it):
koji operates on source packages.
If there's a package in RHEL called 'foo' and also one in EPEL called
'foo' it will use the epel one in all cases for everything that foo
makes.
So, with the limited arch packages this means that _ALL_ things
building in koji will use the epel package. The reason for the
prepended 0 is so that users don't install the epel package and instead
get the newer rhel version. The limited arch guideline also says you
should try and keep the package as close as possible to the rhel
version.
So, if we had say: python-foobar-1.0-1.el7.src.rpm in rhel that made a
python-foobar-1.0-1.noarch.rpm and then we made a epel
python-foobar-1.0-1.el7.src.rpm that had
python3-foobar-1.0-1.noarch.rpm it would mean anything that builds
against python-foobar in epel would break (it would be not found). End
users would be ok, but buildroots could be broken by it.
So we are kinda in a lerch here... I think the best way is just new
packages with python3-whatever.
kevin
4:35 p.m.
On Tue, Sep 13, 2016 at 5:26 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Tue, 13 Sep 2016 14:13:44 -0400
Avram Lubkin <aviso(a)rockhopper.net> wrote:
> I'm looking for some clarification on the naming requirements for
> SRPMs.
>
> In the EPEL 7 in Python 3 Plan Draft [1], it specifies that SRPM names
> can't conflict with RHEL SRPM names, but in the Limited Arch Packages
> [2]section of EPEL: Packaging, it seems to imply the SRPM name would
> be the same, but the release number would be pretended with "0.".
>
> Could someone please clarify?
>
> If, in fact, the name can be the same, it will make it much easier to
> provide Python 3 packages for EPEL since a separate package would not
> be required in the Fedora Package DB.
So, here's the thing (at least as I understand it):
koji operates on source packages.
If there's a package in RHEL called 'foo' and also one in EPEL called
'foo' it will use the epel one in all cases for everything that foo
makes.
So, with the limited arch packages this means that _ALL_ things
building in koji will use the epel package. The reason for the
prepended 0 is so that users don't install the epel package and instead
get the newer rhel version. The limited arch guideline also says you
should try and keep the package as close as possible to the rhel
version.
So, if we had say: python-foobar-1.0-1.el7.src.rpm in rhel that made a
python-foobar-1.0-1.noarch.rpm and then we made a epel
python-foobar-1.0-1.el7.src.rpm that had
python3-foobar-1.0-1.noarch.rpm it would mean anything that builds
against python-foobar in epel would break (it would be not found). End
users would be ok, but buildroots could be broken by it.
So we are kinda in a lerch here... I think the best way is just new
packages with python3-whatever.
That doesn't make sense. Builds are done by pulling in base, epel, and
buildroot repositories into a generated mock config and executed (i.e.
passed to mock to build the SRPM and then the RPMs). No part of mock
would have a problem here. Therefore, there is no reason for the
absurdity of having python3-* SRPMs.
Sure, Koji operates on SRPMs, but Fedora Koji does not build RHEL or
CentOS. So this particular problem doesn't exist from that perspective
either. Content from RHEL/CentOS essentially is a black box to Koji.
--
真実はいつも一つ！/ Always, there's only one truth!
9:48 p.m.
On Tuesday, September 13, 2016 5:35:29 PM CDT Neal Gompa wrote:
On Tue, Sep 13, 2016 at 5:26 PM, Kevin Fenzi <kevin(a)scrye.com>
wrote:
> On Tue, 13 Sep 2016 14:13:44 -0400
>
> Avram Lubkin <aviso(a)rockhopper.net> wrote:
>> I'm looking for some clarification on the naming requirements for
>> SRPMs.
>>
>> In the EPEL 7 in Python 3 Plan Draft [1], it specifies that SRPM names
>> can't conflict with RHEL SRPM names, but in the Limited Arch Packages
>> [2]section of EPEL: Packaging, it seems to imply the SRPM name would
>> be the same, but the release number would be pretended with "0.".
>>
>> Could someone please clarify?
>>
>> If, in fact, the name can be the same, it will make it much easier to
>> provide Python 3 packages for EPEL since a separate package would not
>> be required in the Fedora Package DB.
>
> So, here's the thing (at least as I understand it):
>
> koji operates on source packages.
>
> If there's a package in RHEL called 'foo' and also one in EPEL called
> 'foo' it will use the epel one in all cases for everything that foo
> makes.
>
> So, with the limited arch packages this means that _ALL_ things
> building in koji will use the epel package. The reason for the
> prepended 0 is so that users don't install the epel package and instead
> get the newer rhel version. The limited arch guideline also says you
> should try and keep the package as close as possible to the rhel
> version.
>
> So, if we had say: python-foobar-1.0-1.el7.src.rpm in rhel that made a
> python-foobar-1.0-1.noarch.rpm and then we made a epel
> python-foobar-1.0-1.el7.src.rpm that had
> python3-foobar-1.0-1.noarch.rpm it would mean anything that builds
> against python-foobar in epel would break (it would be not found). End
> users would be ok, but buildroots could be broken by it.
>
> So we are kinda in a lerch here... I think the best way is just new
> packages with python3-whatever.
That doesn't make sense. Builds are done by pulling in base, epel, and
buildroot repositories into a generated mock config and executed (i.e.
passed to mock to build the SRPM and then the RPMs). No part of mock
would have a problem here. Therefore, there is no reason for the
absurdity of having python3-* SRPMs.
Sure, Koji operates on SRPMs, but Fedora Koji does not build RHEL or
CentOS. So this particular problem doesn't exist from that perspective
either. Content from RHEL/CentOS essentially is a black box to Koji.
The koji repos will only include binary packages from exactly one source rpm
of a given name. koji builds its own repos and does not use the repos in the
way you think and you would at home. Koji was tought to treat external repos
exactly the same as internal repos. Net result being if you rebuild python-foo
to get a python3 build you will have to also build python2 version and ensure
that the nvr is lower. The only realistic option given that there will be
python3 mass rebuilds as python versions change is to have python3 specific
srpms
Dennis
5:54 p.m.
> I'm looking for some clarification on the naming requirements
for
> SRPMs.
>
> In the EPEL 7 in Python 3 Plan Draft [1], it specifies that SRPM names
> can't conflict with RHEL SRPM names, but in the Limited Arch Packages
> [2]section of EPEL: Packaging, it seems to imply the SRPM name would
> be the same, but the release number would be pretended with "0.".
>
> Could someone please clarify?
>
> If, in fact, the name can be the same, it will make it much easier to
> provide Python 3 packages for EPEL since a separate package would not
> be required in the Fedora Package DB.
So, here's the thing (at least as I understand it):
koji operates on source packages.
If there's a package in RHEL called 'foo' and also one in EPEL called
'foo' it will use the epel one in all cases for everything that foo
makes.
Is that the case with external repos? I didn't think it was that smart
in that case, but I'm tired so might be mis-remembering.
So, with the limited arch packages this means that _ALL_ things
building in koji will use the epel package. The reason for the
prepended 0 is so that users don't install the epel package and instead
get the newer rhel version. The limited arch guideline also says you
should try and keep the package as close as possible to the rhel
version.
For el7, and even in some of the big (java*) use cases in el6 the
delta in packages between the arches is getting a lot less, and I
believe this will be more so as we move forward in el7.
> So, if we had say: python-foobar-1.0-1.el7.src.rpm in rhel that made a
> python-foobar-1.0-1.noarch.rpm and then we made a epel
> python-foobar-1.0-1.el7.src.rpm that had
> python3-foobar-1.0-1.noarch.rpm it would mean anything that builds
> against python-foobar in epel would break (it would be not found). End
> users would be ok, but buildroots could be broken by it.
>
> So we are kinda in a lerch here... I think the best way is just new
> packages with python3-whatever.
>
> kevin
>
>
>
> _______________________________________________
> epel-devel mailing list
> epel-devel(a)lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraprojec...
>
9:51 p.m.
On Tuesday, September 13, 2016 11:54:41 PM CDT Peter Robinson wrote:
>> I'm looking for some clarification on the naming
requirements for
>> SRPMs.
>>
>> In the EPEL 7 in Python 3 Plan Draft [1], it specifies that SRPM names
>> can't conflict with RHEL SRPM names, but in the Limited Arch Packages
>> [2]section of EPEL: Packaging, it seems to imply the SRPM name would
>> be the same, but the release number would be pretended with "0.".
>>
>> Could someone please clarify?
>>
>> If, in fact, the name can be the same, it will make it much easier to
>> provide Python 3 packages for EPEL since a separate package would not
>> be required in the Fedora Package DB.
>
> So, here's the thing (at least as I understand it):
>
> koji operates on source packages.
>
> If there's a package in RHEL called 'foo' and also one in EPEL called
> 'foo' it will use the epel one in all cases for everything that foo
> makes.
Is that the case with external repos? I didn't think it was that smart
in that case, but I'm tired so might be mis-remembering.
It 100% is the case.
Koji treats external repos exactly the same as internal.
it even taks special care to ensure that all binary rpms for a given srpm are
included even if the binary rpms are spread acorss different external repos
> So, with the limited arch packages this means that _ALL_ things
> building in koji will use the epel package. The reason for the
> prepended 0 is so that users don't install the epel package and instead
> get the newer rhel version. The limited arch guideline also says you
> should try and keep the package as close as possible to the rhel
> version.
For el7, and even in some of the big (java*) use cases in el6 the
delta in packages between the arches is getting a lot less, and I
believe this will be more so as we move forward in el7.
I honestly am not sure
there is any limited arch packages in epel7
> So, if we had say: python-foobar-1.0-1.el7.src.rpm in rhel that
made a
> python-foobar-1.0-1.noarch.rpm and then we made a epel
> python-foobar-1.0-1.el7.src.rpm that had
> python3-foobar-1.0-1.noarch.rpm it would mean anything that builds
> against python-foobar in epel would break (it would be not found). End
> users would be ok, but buildroots could be broken by it.
>
> So we are kinda in a lerch here... I think the best way is just new
> packages with python3-whatever.
>
> kevin
>
>
>
> _______________________________________________
> epel-devel mailing list
> epel-devel(a)lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject
> .org
_______________________________________________
epel-devel mailing list
epel-devel(a)lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.o
rg
3:29 a.m.
On 14/09/16 03:51, Dennis Gilmore wrote:
>> So, with the limited arch packages this means that _ALL_
things
>> building in koji will use the epel package. The reason for the
>> prepended 0 is so that users don't install the epel package and instead
>> get the newer rhel version. The limited arch guideline also says you
>> should try and keep the package as close as possible to the rhel
>> version.
>
> For el7, and even in some of the big (java*) use cases in el6 the
> delta in packages between the arches is getting a lot less, and I
> believe this will be more so as we move forward in el7.
I honestly am not sure there is any limited arch packages in epel7
I think po4a may be one:
https://bugzilla.redhat.com/show_bug.cgi?id=1134624
Paul.
4:38 a.m.
On Wed, Sep 14, 2016 at 3:51 AM, Dennis Gilmore <dennis(a)ausil.us> wrote:
On Tuesday, September 13, 2016 11:54:41 PM CDT Peter Robinson wrote:
> >> I'm looking for some clarification on the naming requirements for
> >> SRPMs.
> >>
> >> In the EPEL 7 in Python 3 Plan Draft [1], it specifies that SRPM names
> >> can't conflict with RHEL SRPM names, but in the Limited Arch Packages
> >> [2]section of EPEL: Packaging, it seems to imply the SRPM name would
> >> be the same, but the release number would be pretended with "0.".
> >>
> >> Could someone please clarify?
> >>
> >> If, in fact, the name can be the same, it will make it much easier to
> >> provide Python 3 packages for EPEL since a separate package would not
> >> be required in the Fedora Package DB.
> >
> > So, here's the thing (at least as I understand it):
> >
> > koji operates on source packages.
> >
> > If there's a package in RHEL called 'foo' and also one in EPEL
called
> > 'foo' it will use the epel one in all cases for everything that foo
> > makes.
>
> Is that the case with external repos? I didn't think it was that smart
> in that case, but I'm tired so might be mis-remembering.
It 100% is the case. Koji treats external repos exactly the same as internal.
it even taks special care to ensure that all binary rpms for a given srpm are
included even if the binary rpms are spread acorss different external repos
> > So, with the limited arch packages this means that _ALL_ things
> > building in koji will use the epel package. The reason for the
> > prepended 0 is so that users don't install the epel package and instead
> > get the newer rhel version. The limited arch guideline also says you
> > should try and keep the package as close as possible to the rhel
> > version.
>
> For el7, and even in some of the big (java*) use cases in el6 the
> delta in packages between the arches is getting a lot less, and I
> believe this will be more so as we move forward in el7.
I honestly am not sure there is any limited arch packages in epel7
There most definitely are, at least in what is shipped, it depends on
the arch and is lessening/changing with each dot release and is much
less of a problem with el7 than earlier releases. The big one that
comes to mind in extras is golang/docker stack.
2778
days inactive
2779
days old
epel-devel@lists.fedoraproject.org
12 comments
8 participants
participants (8)
-
Avram Lubkin -
Dennis Gilmore -
Jim Perrin -
Kevin Fenzi -
Neal Gompa -
Paul Howarth -
Peter Robinson -
Stephen John Smoogen