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

[Raphael Groner]

> 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.

How to maintain the base RPM? Who should maintain this additional repository 
with a deprecation flag? Who's responsible for security fixes?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Raphael Groner]

Hi,

recommending to use %define is wrong. AFAIK our guidelines tell to use %global 
instead.

https://fedoraproject.org/wiki/Packaging:Guidelines#.25global_preferred_over_.25define
(Yes, I know about favoured brand new docs.fp.org but I fail to find a search 
bar or any useful table of contents there. That obviously still needs some 
improvements.)

Regards, Raphael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Pavel Raiskup]

On Thursday, October 4, 2018 1:36:32 PM CEST Charalampos Stratakis wrote:
> This boils down again to having the same SPEC for a bunch of different
> branches which I personally dislike, especially for branches that could
> be ~10 years apart. My main argument against it, is that having a clean
> SPEC file, which could differ slightly between branches, is a lot
> cleaner than having a huge %if spaghetti.

I don't have that general opinion.  Sometimes I need this or that.

But for CI purposes (as an example), it is really really convenient to
have **single** spec file which can be tested against all the platforms
which I still consider "supported".  No matter whether I at the end of
the day really "sync" all the branches in fedora dist-git or not.

Ad "%if-spaghetti" code; this proposal _exactly_ fights against the %if-hell
problem since the logic is moved out from the package to the system.

Pavel



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Charalampos Stratakis]

- Original Message -
> From: "Pavel Raiskup" 
> To: devel@lists.fedoraproject.org
> Sent: Thursday, October 4, 2018 1:05:47 PM
> Subject: Re: Python3 will be in next major RHEL release, please adjust %if 
> statements accordingly
> 
> > 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?
> 
> And once again, what about %py3_build_expected?  Proposed in
> https://bugzilla.redhat.com/show_bug.cgi?id=1636020
> 
> The most obvious argument against that is that it is not 100% bullet
> proof to cover all Fedora Python packages.  But I don't think it is
> a problem in particular; there are _many_ (maybe the most of them)
> python packages that could use this.
> 
> Pavel
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 

This boils down again to having the same SPEC for a bunch of different branches 
which I personally
dislike, especially for branches that could be ~10 years apart. My main 
argument against it, is
that having a clean SPEC file, which could differ slightly between branches, is 
a lot cleaner
than having a huge %if spaghetti.

However, again this is more of a personal preference and I can totally 
understand that having
the same SPEC eases the maintainers' burden by a big margin, our time and 
resources are not
limitless.

Having said that, providing more macros (and maintaining them and take care of 
all the edge cases),
is also a burden for those who implement them. I'd like at least FPC to weigh 
in for that
and if the benefits provided by those macros, would benefit a big chunk of our 
packagers then
I'm all for it. If it would be only though for enabling fast forward merges for 
some cases,
instead of cherry-picking I'd be reluctant to do that.

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Hyperkitty issue? -- Was: Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly

[Pavel Raiskup]

Bug report for those whom it may concern:

I used hyperkitty web-ui to respond into this thread (which was already deleted
in my inbox), and it seems like

 - the "quotation" doesn't work, I reacted on Richard and not Troy
 - the thread has been broken by my message

Pavel

On Thursday, October 4, 2018 1:05:47 PM CEST Pavel Raiskup wrote:
> > 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?
> 
> And once again, what about %py3_build_expected?  Proposed in
> https://bugzilla.redhat.com/show_bug.cgi?id=1636020
> 
> The most obvious argument against that is that it is not 100% bullet
> proof to cover all Fedora Python packages.  But I don't think it is
> a problem in particular; there are _many_ (maybe the most of them)
> python packages that could use this.
> 
> Pavel
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Pavel Raiskup]

> 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?

And once again, what about %py3_build_expected?  Proposed in
https://bugzilla.redhat.com/show_bug.cgi?id=1636020

The most obvious argument against that is that it is not 100% bullet
proof to cover all Fedora Python packages.  But I don't think it is
a problem in particular; there are _many_ (maybe the most of them)
python packages that could use this.

Pavel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Pavel Raiskup]

On Thursday, January 18, 2018 6:11:31 PM CET Petr Viktorin wrote:
> On 01/17/2018 12:38 PM, Richard W.M. Jones wrote:
> > On Thu, Jan 11, 2018 at 01:02:32PM -0800, Troy Dawson wrote:
> >> 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
> > 
> > I'll say it once again, but why can't we just have
> > %{python2_available} and %{python3_available} macros defined in the
> > base system?
> 
> Mostly because we can't change RHEL.

Oxymoron? :-)  Really, why we can not have macros updated?  This case seems to
be worth it.

Pavel

> So, how about %{python2_missing} and %{python3_available}? Is that too 
> ugly and inconsistent?
> 
> 
> -- 
> Petr Viktorin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Building Fedora modules on EL [was Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly]

[Matthew Miller]

On Mon, Jan 22, 2018 at 02:55:37AM -0600, Dennis Gilmore wrote:
> > 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 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.

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.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Building Fedora modules on EL [was Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly]

[Dennis Gilmore]

El jue, 18-01-2018 a las 14:33 -0500, Matthew Miller escribió:
> On Thu, Jan 18, 2018 at 02:09:26PM -0500, Josh Boyer 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.
> > 
> > You're referring to EPEL > 7, right? 
> 
> For Python, yes.
> 
> >   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?

> 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 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.

> 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.

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.

> 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.

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

> 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.
agreed.

Dennis


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Exploring the idea of CentOS/RHEL branches in dist-git [was Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly]

[James Hogarth]

On 17 January 2018 at 17:13, Matthew Miller  wrote:
> On Tue, Jan 16, 2018 at 08:18:42AM -0500, Josh Boyer wrote:
>> - 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?
>
> 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.
>

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
;)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Building Fedora modules on EL [was Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly]

[Matthew Miller]

On Thu, Jan 18, 2018 at 02:09:26PM -0500, Josh Boyer 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.
> You're referring to EPEL > 7, right? 

For Python, yes.

>   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?

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.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Josh Boyer]

On Thu, Jan 18, 2018 at 1:45 PM, Matthew Miller
 wrote:
> On Thu, Jan 18, 2018 at 07:32:07PM +0100, Miro Hrončok wrote:
>> Once there is a new EPEL version out there, it is very likely both
>> pythons will be available there as well.
>
> 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.

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Stephen John Smoogen]

On 18 January 2018 at 13:45, Matthew Miller  wrote:
> On Thu, Jan 18, 2018 at 07:32:07PM +0100, Miro Hrončok wrote:
>> Once there is a new EPEL version out there, it is very likely both
>> pythons will be available there as well.
>
> 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.
>

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.

> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Matthew Miller]

On Thu, Jan 18, 2018 at 07:32:07PM +0100, Miro Hrončok wrote:
> Once there is a new EPEL version out there, it is very likely both
> pythons will be available there as well.

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.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Miro Hrončok]

On 18.1.2018 19:16, Stephen Gallagher wrote:



On Thu, Jan 18, 2018 at 12:12 PM Petr Viktorin > wrote:


On 01/17/2018 12:38 PM, Richard W.M. Jones wrote:
 > On Thu, Jan 11, 2018 at 01:02:32PM -0800, Troy Dawson wrote:
 >> 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
 >
 > I'll say it once again, but why can't we just have
 > %{python2_available} and %{python3_available} macros defined in the
 > base system?

Mostly because we can't change RHEL.

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



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?


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?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Stephen Gallagher]

On Thu, Jan 18, 2018 at 12:12 PM Petr Viktorin  wrote:

> On 01/17/2018 12:38 PM, Richard W.M. Jones wrote:
> > On Thu, Jan 11, 2018 at 01:02:32PM -0800, Troy Dawson wrote:
> >> 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
> >
> > I'll say it once again, but why can't we just have
> > %{python2_available} and %{python3_available} macros defined in the
> > base system?
>
> Mostly because we can't change RHEL.
>
> So, how about %{python2_missing} and %{python3_available}? Is that too
> ugly and inconsistent?
>
>

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?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Petr Viktorin]

On 01/17/2018 12:38 PM, Richard W.M. Jones wrote:

On Thu, Jan 11, 2018 at 01:02:32PM -0800, Troy Dawson wrote:

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


I'll say it once again, but why can't we just have
%{python2_available} and %{python3_available} macros defined in the
base system?


Mostly because we can't change RHEL.

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



--
Petr Viktorin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Exploring the idea of CentOS/RHEL branches in dist-git [was Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly]

[Matthew Miller]

On Tue, Jan 16, 2018 at 08:18:42AM -0500, Josh Boyer wrote:
> - 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?

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.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Richard W.M. Jones]

On Thu, Jan 11, 2018 at 01:02:32PM -0800, Troy Dawson wrote:
> 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

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.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Exploring the idea of CentOS/RHEL branches in dist-git [was Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly]

[Neal Gompa]

On Tue, Jan 16, 2018 at 8:18 AM, Josh Boyer  wrote:
> On Tue, Jan 16, 2018 at 8:01 AM, Neal Gompa  wrote:
>> On Sat, Jan 13, 2018 at 12:39 PM, Matthew Miller
>>  wrote:
>>> On Sat, Jan 13, 2018 at 10:40:36AM +0100, Kevin Kofler 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.
>>>
>>> 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?
>>>
>>
>> (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.
>
> I was wondering about the ACLs myself.
>
>> 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.
>
> 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.
>

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.

>>
>> 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. :)
>
> Well, I'm glad you did.  At least the conversation is flowing.
>

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


On Tue, Jan 16, 2018 at 8:35 AM, Stephen Gallagher  wrote:
>
> On Tue, Jan 16, 2018 at 8:20 AM Josh Boyer 
> wrote:
>>
>> 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?
>>
>
> Having such branches available could help with EPEL as well. In RHEL 7, we
> had no official python3 packages in the main repositories, so EPEL 7 tended
> to carry them. Having an EPEL branch that can easily pull from the
> RHEL/CentOS branch and apply just the diff necessary to build the missing
> pieces would be very handy (and easier on maintainers to keep up-to-date).
> This in turn might lead to people being more inclined to maintain things in
> EPEL.

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.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedorapro

Re: Exploring the idea of CentOS/RHEL branches in dist-git [was Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly]

[Stephen Gallagher]

On Tue, Jan 16, 2018 at 8:20 AM Josh Boyer 
wrote:

> On Tue, Jan 16, 2018 at 8:01 AM, Neal Gompa
> > 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.
>
> 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.
>
> > 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.
>
> 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?
>
>
Having such branches available could help with EPEL as well. In RHEL 7, we
had no official python3 packages in the main repositories, so EPEL 7 tended
to carry them. Having an EPEL branch that can easily pull from the
RHEL/CentOS branch and apply just the diff necessary to build the missing
pieces would be very handy (and easier on maintainers to keep up-to-date).
This in turn might lead to people being more inclined to maintain things in
EPEL.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Exploring the idea of CentOS/RHEL branches in dist-git [was Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly]

[Josh Boyer]

On Tue, Jan 16, 2018 at 8:01 AM, Neal Gompa  wrote:
> On Sat, Jan 13, 2018 at 12:39 PM, Matthew Miller
>  wrote:
>> On Sat, Jan 13, 2018 at 10:40:36AM +0100, Kevin Kofler 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.
>>
>> 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?
>>
>
> (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.

I was wondering about the ACLs myself.

> 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.

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.

> 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.

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?

> [1]: https://build.opensuse.org/project/show/SUSE:SLE-15:GA
>
>> 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.
>>
>
> 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.

Right.

> On Tue, Jan 16, 2018 at 7:43 AM, Josh Boyer  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.
>>
>
> 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. :)

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

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Exploring the idea of CentOS/RHEL branches in dist-git [was Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly]

[Neal Gompa]

On Sat, Jan 13, 2018 at 12:39 PM, Matthew Miller
 wrote:
> On Sat, Jan 13, 2018 at 10:40:36AM +0100, Kevin Kofler 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.
>
> 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?
>

(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]: https://build.opensuse.org/project/show/SUSE:SLE-15:GA

> 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.
>

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  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.
>

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. :)

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Exploring the idea of CentOS/RHEL branches in dist-git [was Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly]

[Josh Boyer]

On Sat, Jan 13, 2018 at 12:39 PM, Matthew Miller
 wrote:
> On Sat, Jan 13, 2018 at 10:40:36AM +0100, Kevin Kofler 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.
>
> 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.

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Exploring the idea of CentOS/RHEL branches in dist-git [was Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly]

[Matthew Miller]

On Sat, Jan 13, 2018 at 10:40:36AM +0100, Kevin Kofler 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.

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.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Kevin Kofler]

Peter Robinson 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.

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Peter Robinson]

On Sat, Jan 13, 2018 at 1:36 AM, Kevin Kofler  wrote:
> Jason L Tibbitts III wrote:
>> 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
>
> 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…

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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Kevin Kofler]

Jason L Tibbitts III wrote:
> 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

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Neal Gompa]

On Fri, Jan 12, 2018 at 7:05 AM, Josh Boyer  wrote:
> On Thu, Jan 11, 2018 at 9:04 PM, Adam Williamson
>  wrote:
>> On Thu, 2018-01-11 at 20:53 -0500, Josh Boyer wrote:
>>> 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.
>>
>> Look out for RHEL IT'S OVER 9000!, coming soon...
>
> Red Hat Enterprise Linux 9001 (Goku)
>

I'll buy that! 😜



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Troy Dawson]

On Thu, Jan 11, 2018 at 11:55 PM, Panu Matilainen  wrote:
> On 01/12/2018 06:08 AM, Luya Tshimbalanga wrote:
>>
>> On 2018-01-11 01:02 PM, Troy Dawson wrote:
>>>
>>> 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
>>> ___
>>
>>
>> Quick question: why not using %global rather than %define ?
>>
>
> Probably old habit from times before %define got unnecessarily demonized
> within Fedora. FWIW, both achieve exactly the same thing in this context.
>

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Josh Boyer]

On Thu, Jan 11, 2018 at 9:04 PM, Adam Williamson
 wrote:
> On Thu, 2018-01-11 at 20:53 -0500, Josh Boyer wrote:
>> 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.
>
> Look out for RHEL IT'S OVER 9000!, coming soon...

Red Hat Enterprise Linux 9001 (Goku)

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Panu Matilainen]

On 01/12/2018 06:08 AM, Luya Tshimbalanga wrote:

On 2018-01-11 01:02 PM, Troy Dawson wrote:

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
___


Quick question: why not using %global rather than %define ?



Probably old habit from times before %define got unnecessarily demonized 
within Fedora. FWIW, both achieve exactly the same thing in this context.


- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Luya Tshimbalanga]

On 2018-01-11 01:02 PM, Troy Dawson wrote:
> 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
> ___

Quick question: why not using %global rather than %define ?

-- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Adam Williamson]

On Thu, 2018-01-11 at 20:53 -0500, Josh Boyer wrote:
> 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.

Look out for RHEL IT'S OVER 9000!, coming soon...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Josh Boyer]

On Thu, Jan 11, 2018 at 8:32 PM, Jason L Tibbitts III  wrote:
>> "JB" == Josh Boyer  writes:
>
> 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.

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 :).

> 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.

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

> 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

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.

> 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.

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.

> 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.)

That would be interesting to see.

> 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.

We were both surprised then!

> 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.

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 inst

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

[Jason L Tibbitts III]

> "JB" == Josh Boyer  writes:

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<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Josh Boyer]

On Thu, Jan 11, 2018 at 4:34 PM, Jason L Tibbitts III  wrote:
>> "FW" == Florian Weimer  writes:
>
> 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.

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Jason L Tibbitts III]

> "FW" == Florian Weimer  writes:

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<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Florian Weimer]

On 01/11/2018 10:09 PM, Jason L Tibbitts III wrote:

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.


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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Jason L Tibbitts III]

> "TD" == Troy Dawson  writes:

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<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Troy Dawson]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org