DevHeads.net

Python3 will be in next major RHEL release, please adjust %if statements accordingly

Hello,
Python3 will be in the next major RHEL release. I don't mean RHEL
7.6, but with numbers higher than 7.
There are many, many packages with something like the following

if 0%{?fedora}
%define with_python3 1
%endif

If you have something like that, please change it to something like this.

if 0%{?fedora} || 0%{?rhel} > 7
%define with_python3 1
%endif

Thank You

Comments

Re: Python3 will be in next major RHEL release, please adjust %i

By Richard W.M. Jones at 01/17/2018 - 07:38

On Thu, Jan 11, 2018 at 01:02:32PM -0800, Troy Dawson wrote:
I'll say it once again, but why can't we just have
%{python2_available} and %{python3_available} macros defined in the
base system?

Rich.

Re: Python3 will be in next major RHEL release, please adjust %i

By Petr Viktorin at 01/18/2018 - 13:11

On 01/17/2018 12:38 PM, Richard W.M. Jones wrote:
Mostly because we can't change RHEL.

So, how about %{python2_missing} and %{python3_available}? Is that too
ugly and inconsistent?

Re: Python3 will be in next major RHEL release, please adjust %i

By Pavel Raiskup at 02/01/2018 - 14:50

On Thursday, January 18, 2018 6:11:31 PM CET Petr Viktorin wrote:
Oxymoron? :-) Really, why we can not have macros updated? This case seems to
be worth it.

Pavel

Re: Python3 will be in next major RHEL release, please adjust %i

By Stephen Gallagher at 01/18/2018 - 14:16

We don't need to change RHEL. We just need to add %{python2_available} to
the epel-srpm-macros package. Or am I missing something? Yes, this will
only work for packages built against EPEL 7 and not for third-party
build-systems, but that's not something we have to care about, is it?

Re: Python3 will be in next major RHEL release, please adjust %i

By =?UTF-8?B?TWlyb... at 01/18/2018 - 14:32

On 18.1.2018 19:16, Stephen Gallagher wrote:
Well there's python3 and python2 available in all EPEL versions and all
Fedora versions.

Once there is a new EPEL version out there, it is very likely both
pythons will be available there as well.

What am I missing?

Re: Python3 will be in next major RHEL release, please adjust %i

By Matthew Miller at 01/18/2018 - 14:45

On Thu, Jan 18, 2018 at 07:32:07PM +0100, Miro Hrončok wrote:
Given that Python 2 is going EOL in about two years, I don't think we
want it in EPEL proper. If we do provide it, it should be in a module.

Re: Python3 will be in next major RHEL release, please adjust %i

By Josh Boyer at 01/18/2018 - 15:09

On Thu, Jan 18, 2018 at 1:45 PM, Matthew Miller
< ... at fedoraproject dot org> wrote:
You're referring to EPEL > 7, right? Also, that last part is kind of
a leap in assumption. Perhaps it's because I'm not up to speed on
EPEL plans, but do we have timelines for when/if modules will be
created for and available for EPEL?

josh

Building Fedora modules on EL [was Re: Python3 will be in next m

By Matthew Miller at 01/18/2018 - 15:33

On Thu, Jan 18, 2018 at 02:09:26PM -0500, Josh Boyer wrote:
For Python, yes.

It's the plan of record that by default, all modules will be built
across all available buildroots. I'm not sure if that means EPEL7 will
be an available option for technical reasons, but I hope so. This will
possibly require a modular-capable DNF in EPEL proper or in a side-repo
of some sort -- TBD. But if that works, we'll start having modular
content for EL right along with the F28 release.

If not, it'll have to wait for the "higher than 7" RHEL release, but
should be able to enable module building for that pretty quickly once
the target OS is available.

I know that many of us Fedora packagers stay away from EPEL, but at
least for me, that's largely because I'm not confident about committing
to the long lifecycle, because to keep packages stable I'd have to
diverge from Fedora, and because rpm abilities lag so much.

With modules, the first two concerns are handled (because I can
maintain my modules with whatever commitments I feel comfortable with,
even with an EL target). And at least initially the RPM/DNF functionality
should be on par with modern Fedora.

Re: Building Fedora modules on EL [was Re: Python3 will be in ne

By Dennis Gilmore at 01/22/2018 - 04:55

El jue, 18-01-2018 a las 14:33 -0500, Matthew Miller escribió:
If this is something we want to do in that timeline things need to be
getting put in place now. We should have a discssion about what we
would like, what timelines we would do it on, and how it would all look
and work. The DNF and RPM teams probably need to chime in to let us
know what is practical. in order to have it in the F28 timeline we need
to get it enabled in the next 6-8 weeks.

What EPEL greater than 7 looks like will be a discussion to be had when
there is something to build against relased publicly, until we see
what the base looks like we can not determine what EPEL will look like.

This is a big issue, it is a commitment, people have thier own ideas on
what stable and supported in EPEL means.

Dennis

Re: Building Fedora modules on EL [was Re: Python3 will be in ne

By Matthew Miller at 01/22/2018 - 15:24

On Mon, Jan 22, 2018 at 02:55:37AM -0600, Dennis Gilmore wrote:
Good point -- I'm not sure this got into the "todo list" when we had
the last discussion about it. To be clear, this definitely shouldn't
hold up any work on getting the basic functionality for F28 in place.
We might have to scale back my dream to "right along with the F29
release" -- but I hope not.

Re: Python3 will be in next major RHEL release, please adjust %i

By Stephen John Smoogen at 01/18/2018 - 15:07

On 18 January 2018 at 13:45, Matthew Miller < ... at fedoraproject dot org> wrote:
It has been requested by multiple people to go into EPEL proper. I
honestly don't expect any uptake on modules in EPEL land until
RHEL-8.2 in the same way that other Fedora items from 18 weren't
wanted by people until it had 'solidified' in RHEL-7.3. Modules are
something which is landing in the distro just now and we aren't
shipping a working distro that Enterprise people can say "Oh that
would be useful".. at the moment they will just reply "That's horse
pucky" because it is the default answer to vendor software until
proven otherwise.

Modules will get used, but I expect that the majority of initial users
will just want what they had before.. with just newer versions. My
current idea is to have python27 from RHEL-7 for as long as RHEL-7 is
around. It would either sit in /usr/bin or /opt/epel depending on what
is easier for developers. It is the standard issue with the
innovator's dilemna. The audience we know we have wants things like
they had because they have already sunk costs in it. We have to find
the new audience that wants the innovation versus expecting the
existing one to use it OR that the new one will come to us.

Re: Python3 will be in next major RHEL release, please adjust %i

By Luya Tshimbalanga at 01/12/2018 - 00:08

On 2018-01-11 01:02 PM, Troy Dawson wrote:
Quick question: why not using %global rather than %define ?

Re: Python3 will be in next major RHEL release, please adjust %i

By Panu Matilainen at 01/12/2018 - 03:55

On 01/12/2018 06:08 AM, Luya Tshimbalanga wrote:
Probably old habit from times before %define got unnecessarily demonized
within Fedora. FWIW, both achieve exactly the same thing in this context.

Re: Python3 will be in next major RHEL release, please adjust %i

By Troy Dawson at 01/12/2018 - 09:58

On Thu, Jan 11, 2018 at 11:55 PM, Panu Matilainen < ... at redhat dot com> wrote:
When writing this email I grabbed the last package that I looked at.
There is a wide variety of these %if statements, ranging from %define
and %global, and different ways of setting "with_python3", to putting
the %if statement around each python3 part of the spec file.
Because of this wide variety, it would be difficult to script a
rewrite of spec files.

Troy

Re: Python3 will be in next major RHEL release, please adjust %i

By Jason L Tibbitts III at 01/11/2018 - 17:09

TD> If you have something like that, please change it to something like
TD> this.

TD> if 0%{?fedora} || 0%{?rhel} > 7
TD> %define with_python3 1
TD> %endif

If things work as they have in the past, packages will need to
explicitly be branched for EPEL8 and so that would be an obvious time to
fix that kind of thing up. If a package isn't branched for EPEL8 then
it doesn't really matter.

In any case, we really should just have a %python3_available macro or
something like that which we can use, and then set that appropriately in
either redhat-rpm-config or epel-rpm-macros. For all I know we might
have that already. But this mess of trying to keep track of what each
individual release has or doesn't have is too complicated.

- J<

Re: Python3 will be in next major RHEL release, please adjust %i

By Florian Weimer at 01/11/2018 - 17:30

On 01/11/2018 10:09 PM, Jason L Tibbitts III wrote:
It could also be branched into Red Hat Enterprise Linux proper, and in
that case, it would be nice to minimize the differences.

Thanks,
Florian

Re: Python3 will be in next major RHEL release, please adjust %i

By Jason L Tibbitts III at 01/11/2018 - 17:34

FW> It could also be branched into Red Hat Enterprise Linux proper, and
FW> in that case, it would be nice to minimize the differences.

That would be kind of outside the scope of Fedora, though. Many of us
watching from outside would assume that instructions on handling that
would have gone to the maintainers of those packages in RHEL via
internal Red Hat management channels.

- J<

Re: Python3 will be in next major RHEL release, please adjust %i

By Josh Boyer at 01/11/2018 - 20:53

On Thu, Jan 11, 2018 at 4:34 PM, Jason L Tibbitts III < ... at math dot uh.edu> wrote:
Hm. On the one hand, that's a fair assumption to make. On the other
hand, it seems unnecessarily adversarial.

I kind of thought we were past the point where Fedora and Red Hat
Enterprise Linux were somehow viewed as anything other than symbiotic
in their relationship. As a direct result of that, the relationship
between the Fedora community and Red Hat should be both collaborative
and symbiotic. To be frank, Fedora cannot exist without the corporate
sponsorship Red Hat provides. To be as equally frank, the value the
Fedora community provides back to Red Hat in the form of contributions
in Fedora that directly impact (and improve!) RHEL is extremely high.

So when a community member reaches out and asks people to help out
with a small change to packages that *already* conditionalize
something, I don't see why that isn't a reasonable request. While a
number of these packages are likely maintained by a common person in
Fedora and RHEL, not all of them are. Further, the packages found in
current RHEL do not necessarily represent the packages found in future
versions.

At the very least, I did not expect a discussion about the scope of
Fedora with such a small request. It would have been pretty trivial
to script this and use a provenpackager to make the changes across the
board. Instead of doing this by fiat, this seems like an attempt to
be proactive and inclusive even if the impact isn't *directly* a
Fedora specific change. I would hope our community would view that as
a positive thing.

josh

Re: Python3 will be in next major RHEL release, please adjust %i

By Jason L Tibbitts III at 01/11/2018 - 21:32

JB> Hm. On the one hand, that's a fair assumption to make. On the
JB> other hand, it seems unnecessarily adversarial.

I certainly didn't intend it that way; hell, none of that even entered
my mind. To flip it around, to be completely honest your response comes
off just this side of overly defensive (which I would wager you also
didn't intend). But you brought it up, so here's my thought process.

As a person not privy to Red Hat internals, I really have no idea what
state things are in there, but I have to assume that Red Hat is well
along with RHEL8 packaging and so I would be surprised if any changes
made to a rawhide branch in Fedora now would make any difference to how
RHEL8 builds.

So think of it from my perspective, not having any knowledge of Red Hat
release dates and policy. My interpretation of what Florian wrote was
that doing this (I assumed in rawhide) could potentially help the RHEL8
developers. Which is great; everyone needs all the help they can get.
But if that's the case, then either RHEL8 hasn't even been branched yet
or it has been branched and someone has already had to make those
changes and they didn't flow back out to Fedora. I certainly thought
RHEL8 was further along than that, so....

JB> So when a community member reaches out and asks people to help out
JB> with a small change to packages that *already* conditionalize
JB> something, I don't see why that isn't a reasonable request.

I never intended to imply that it wasn't. Only that it wouldn't really
matter, and that I didn't think it was worth making any big effort to
convert these things, since things have to be manually branched into
EPEL8 anyway so the maintainer who wants to have them branched there can
simply fix them then.

And of course I offered another solution to this kind of thing, which
would fix a whole class of this kind of thing for all time, but that
idea never seems to get any traction. (Probably because I never find
the time to push it forward.)

JB> At the very least, I did not expect a discussion about the scope of
JB> Fedora with such a small request.

I didn't either, but then I was quite surprised to see a suggestion that
a community member changing an %if clause in a Fedora package now would
somehow make any difference to what RHEL8 is certainly already doing.

JB> It would have been pretty trivial to script this and use a
JB> provenpackager to make the changes across the board.

Well, we do have a procedure for doing that and which even encourages
such things. I don't think it's an entirely trivial problem, though,
but certainly if someone wants to take it up I'm not going to object.

- J<

Re: Python3 will be in next major RHEL release, please adjust %i

By Kevin Kofler at 01/12/2018 - 21:36

Jason L Tibbitts III wrote:
I really wish RHEL were developed more openly. Even without making the
branches public, at least informing Fedora maintainers about when they
branch from Rawhide would already help preventing unnecessary work. And for
some packages, the contents end up leaking out to Rawhide (under %{?rhel}
conditionals) anyway, so I'm not even all that sure hiding the branches is
all that useful. The code will hopefully eventually end up in CentOS git
anyway. But of course I don't expect anybody to listen to me…

Kevin Kofler

Re: Python3 will be in next major RHEL release, please adjust %i

By Peter Robinson at 01/12/2018 - 22:46

On Sat, Jan 13, 2018 at 1:36 AM, Kevin Kofler <kevin. ... at chello dot at> wrote:
Well given it's based on Fedora and most of the pre work happens in
Fedora (hence the request for ensuring the conditionals are correct) I
think that's relatively upstream. Also a lot of the packages actually
have the same specs in Fedora/RHEL/CentOS, a lot of the RHEL stuff is
rebased regularly and those maintainers keep things in sync, but like
everything different maintainers work in different ways/workflows so
some do diverge over the lifecycle of a RHEL release, but that's
generally seen quite easily via the centos dist-git instance.

Re: Python3 will be in next major RHEL release, please adjust %i

By Kevin Kofler at 01/13/2018 - 05:40

Peter Robinson wrote:
That's just all the more reason to publish the branched packages in CentOS
Git as soon as they're branched, or even maintain them in Fedora dist-git.
But I'm not holding my breath for it to happen any time soon.

Kevin Kofler

Exploring the idea of CentOS/RHEL branches in dist-git [was Re:

By Matthew Miller at 01/13/2018 - 13:39

On Sat, Jan 13, 2018 at 10:40:36AM +0100, Kevin Kofler wrote:
I wouldn't suggest holding breath, exactly, but let's entertain the
idea. (I mean, at the very least, hey, it's open source, and we could
import branches from CentOS dist-git if we found a benefit from it....)

If we did this in Fedora dist-git, how would people feel about having a
RHEL/CentOS branch which is effectively owned by the company? Since the
Core/Extras merge, we've striven to avoid cases where Red Hat has
special access. This wouldn't introduce any regression in that to
Fedora-OS branches themselves, but there would be some
"company-specialness" which we've kept away from. Is that okay?

I guess theoretically with arbitrary branching, we could allow special
branches like this for *any* purpose, like other remixes or variants as
approved by the community (assuming open source and legally possible)
-- it wouldn't have to be Red Hat _especially_ special. RH branches
would just be a case of that.

Re: Exploring the idea of CentOS/RHEL branches in dist-git [was

By King InuYasha at 01/16/2018 - 09:01

On Sat, Jan 13, 2018 at 12:39 PM, Matthew Miller
< ... at fedoraproject dot org> wrote:
(just a nit, but I think you mean "strived")

Didn't we *just* lose this functionality (per branch ACLs) when we
moved to Pagure? That being said, while I would *love* for RHEL
branches to be part of the Fedora Dist-Git, I really doubt it would
happen. That said, syncing in the CentOS branches into the tree would
be interesting, and make it much easier to see where things lie w.r.t.
changes between Fedora and RHEL.

It's interesting that you bring this up, because SUSE elected to do
this for the SLE 15 development[1]. All the sources are public, and
while only a few things (a few bots and SUSE employees) can submit
into SLE 15, it's been helping them with the Leap 15 development and
for making sure stuff is properly synchronized between Factory (their
equivalent of Rawhide), the openSUSE Leap 15 development tree, and the
SUSE Linux Enterprise 15 development tree. Technically, I can
indirectly contribute to SLE 15 through submitting change requests to
the Leap 15 project, which has some interesting implications.

The holy grail would be allowing people to submit PRs that Red Hat
folks could consider to include into RHEL 8, but honestly, I don't
think it'll happen. I even doubt we'd be able to have EL branches of
packages merged into Dist-Git. And mirroring CentOS branches is not
particularly useful (though their Git frontend is garbage...), a link
to the package in CentOS Git would be sufficient for people to find
the equivalent in CentOS for Fedora packages.

[1]: <a href="https://build.opensuse.org/project/show/SUSE:SLE-15:GA" title="https://build.opensuse.org/project/show/SUSE:SLE-15:GA">https://build.opensuse.org/project/show/SUSE:SLE-15:GA</a>

But it's not arbitrary branching, and please don't treat it as such.
It's the same type of branching we do for Fedora. Mixing concepts like
that will give people ideas of things that aren't there.

On Tue, Jan 16, 2018 at 7:43 AM, Josh Boyer < ... at fedoraproject dot org> wrote:
At first, I missed it. Then I read it, and I blinked in disbelief.
Then I decided to write a response, and then forgot to send it. Now I
sent it. :)

Re: Exploring the idea of CentOS/RHEL branches in dist-git [was

By Josh Boyer at 01/16/2018 - 09:18

On Tue, Jan 16, 2018 at 8:01 AM, Neal Gompa < ... at gmail dot com> wrote:
I was wondering about the ACLs myself.

This is interesting, but I wonder how often we shoot ourselves in the
foot by comparing an idea to what someone else kind of already did
that's similar but not exactly the same. I'd rather see us take an
idea and evaluate what we, Fedora, want out of it. And I know we kill
ideas because of doubt, so let's not do that right now. Let's go
through the exercise and see if this is something that will be
beneficial and *worth* discussing with Red Hat rather than just
assuming it would be shot down.

So a few specific theoretical benefits would be:

- Better Git frontend for CentOS
- Possibility to submit PRs against RHEL branches
- Easy to see changes from RHEL and Fedora (and CentOS).

What are some others?

Right.

Well, I'm glad you did. At least the conversation is flowing.

josh

Re: Exploring the idea of CentOS/RHEL branches in dist-git [was

By Matthew Miller at 01/17/2018 - 13:13

On Tue, Jan 16, 2018 at 08:18:42AM -0500, Josh Boyer wrote:
I'd like to see these branches as candidates for inclusion in modules
built on Fedora bases. That way, we'd have a maintained source of
slower-moving dependencies.

Re: Exploring the idea of CentOS/RHEL branches in

By James Hogarth at 01/19/2018 - 08:38

On 17 January 2018 at 17:13, Matthew Miller < ... at fedoraproject dot org> wrote:
I'm looping in the CentOS development list as this is all just pipe
dreams and fairy whispers if no one gives them a heads up for feedback
;)

Re: Exploring the idea of CentOS/RHEL branches in dist-git [was

By King InuYasha at 01/16/2018 - 10:28

On Tue, Jan 16, 2018 at 8:18 AM, Josh Boyer < ... at fedoraproject dot org> wrote:
I do the comparisons because I want us to be able to learn from what
other people do. The goal is to take the idea, and do it better. For
example, SUSE's model has an indirect contribution model. A way for us
to improve on the idea is to allow PRs to directly contribute
improvements to EL branches.

As for the doubts, I just didn't want to get my hopes up... But I
definitely have wishes about what I would like to see, as I outlined.

Indeed. I think there's an interesting opportunity here.

On Tue, Jan 16, 2018 at 8:35 AM, Stephen Gallagher < ... at redhat dot com> wrote:
It's not just this, though. Packages transition between EPEL and RHEL
quite a bit, and if it were as simple as just renaming a branch and
changing the ACLs, that would make things much better. Also, it would
bring some more consistency to how EPEL operates and less surprises. I
know one of the reasons I don't do too many packages in EPEL anymore
is because I get surprised too often by what RHEL does. It's just not
worth it to deal with that mess unless someone really wants it.

Re: Exploring the idea of CentOS/RHEL branches in dist-git [was

By Stephen Gallagher at 01/16/2018 - 09:35

On Tue, Jan 16, 2018 at 8:20 AM Josh Boyer < ... at fedoraproject dot org>
wrote:

Re: Exploring the idea of CentOS/RHEL branches in dist-git [was

By Josh Boyer at 01/16/2018 - 08:43

On Sat, Jan 13, 2018 at 12:39 PM, Matthew Miller
< ... at fedoraproject dot org> wrote:
I'm surprised you've gotten 0 replies to this at all. I can't tell if
that is because people didn't really catch the subject, or if people
aren't interested, or they don't see the benefit?

I, for one, find the topic interesting. I'd like to see a more
fleshed out idea of why we'd do that though.

josh

Re: Python3 will be in next major RHEL release, please adjust %i

By Josh Boyer at 01/11/2018 - 21:53

On Thu, Jan 11, 2018 at 8:32 PM, Jason L Tibbitts III < ... at math dot uh.edu> wrote:
Indeed. I didn't mean to sound defensive. I also didn't think you
had any malice behind your reply for what it's worth. I was surprised
by the tone of indifference. It caught me off-guard.

I intended to invoke discussion about the "scope" comment. I
succeeded there at least, even if I failed in other ways :).

Assumptions are bad. Not being able to talk about future looking
events is awkward. Red Hat is trying to get better at both.

Small caveat, nobody said RHEL 8. Troy said the next major version of
RHEL will have python3, that's all. This is where the awkwardness
comes in. I think people can appreciate not being able to talk
publicly about any current or future development activities for
unreleased products.

As for the assumption on when/if/how RHEL development occurs, those
are easy to make and I don't fault anyone for thinking along the lines
you laid out. I would offer that Troy would not have made a request
if it was pointless to do so. That benefits nobody. I would also
suggest that by making the request, he isn't assuming he can just
script and fix without coordination.

Right, that's what I mean though. It's a small change that a
community member asked for help with. If we approach that with
positive intent in mind, he's asking because it *does* matter in some
way.

And if you'll allow me a little latitude, I'd also point out that
while there are many package maintainers that maintain across the
Fedora and RHEL divide, Red Hat is an open source company. Fedora in
an upstream for RHEL, and whenever possible it tries to contribute
back to the upstream source to lessen burden for those maintainers.
The more the specs are shared, the further that benefit goes. To do
otherwise would be weird.

That would be interesting to see.

We were both surprised then!

I think, in this case, we'd like to avoid that. I get that people
don't always read devel list so the request and this discussion might
not even register to the majority of maintainers. At least we have it
in the archives for reference though.

Thanks for your willingness to discuss. I love it when something
starts trending toward understanding instead of escalating into a
flamefest!

josh

Re: Python3 will be in next major RHEL release, please adjust %i

By Adam Williamson at 01/11/2018 - 22:04

On Thu, 2018-01-11 at 20:53 -0500, Josh Boyer wrote:
Look out for RHEL IT'S OVER 9000!, coming soon...

Re: Python3 will be in next major RHEL release, please adjust %i

By Josh Boyer at 01/12/2018 - 08:05

On Thu, Jan 11, 2018 at 9:04 PM, Adam Williamson
< ... at fedoraproject dot org> wrote:
Red Hat Enterprise Linux 9001 (Goku)

josh

Re: Python3 will be in next major RHEL release, please adjust %i

By King InuYasha at 01/12/2018 - 10:34

On Fri, Jan 12, 2018 at 7:05 AM, Josh Boyer < ... at fedoraproject dot org> wrote:
I'll buy that!