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
"TD" == Troy Dawson tdawson@redhat.com 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<
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
"FW" == Florian Weimer fweimer@redhat.com 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<
On Thu, Jan 11, 2018 at 4:34 PM, Jason L Tibbitts III tibbs@math.uh.edu wrote:
"FW" == Florian Weimer fweimer@redhat.com 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
"JB" == Josh Boyer jwboyer@fedoraproject.org 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<
On Thu, Jan 11, 2018 at 8:32 PM, Jason L Tibbitts III tibbs@math.uh.edu wrote:
"JB" == Josh Boyer jwboyer@fedoraproject.org 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 instead of escalating into a flamefest!
josh
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...
On Thu, Jan 11, 2018 at 9:04 PM, Adam Williamson adamwill@fedoraproject.org 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
On Fri, Jan 12, 2018 at 7:05 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Jan 11, 2018 at 9:04 PM, Adam Williamson adamwill@fedoraproject.org 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! 😜
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
On Sat, Jan 13, 2018 at 1:36 AM, Kevin Kofler kevin.kofler@chello.at 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.
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
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.
On Sat, Jan 13, 2018 at 12:39 PM, Matthew Miller mattdm@fedoraproject.org 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
On Sat, Jan 13, 2018 at 12:39 PM, Matthew Miller mattdm@fedoraproject.org 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 jwboyer@fedoraproject.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.
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. :)
On Tue, Jan 16, 2018 at 8:01 AM, Neal Gompa ngompa13@gmail.com wrote:
On Sat, Jan 13, 2018 at 12:39 PM, Matthew Miller mattdm@fedoraproject.org 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?
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 jwboyer@fedoraproject.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.
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
On Tue, Jan 16, 2018 at 8:20 AM Josh Boyer jwboyer@fedoraproject.org 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.
On Tue, Jan 16, 2018 at 8:18 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Jan 16, 2018 at 8:01 AM, Neal Gompa ngompa13@gmail.com wrote:
On Sat, Jan 13, 2018 at 12:39 PM, Matthew Miller mattdm@fedoraproject.org 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 sgallagh@redhat.com wrote:
On Tue, Jan 16, 2018 at 8:20 AM Josh Boyer jwboyer@fedoraproject.org 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.
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.
On 17 January 2018 at 17:13, Matthew Miller mattdm@fedoraproject.org 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 ;)
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 ?
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 -
On Thu, Jan 11, 2018 at 11:55 PM, Panu Matilainen pmatilai@redhat.com 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
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.
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?
On Thu, Jan 18, 2018 at 12:12 PM Petr Viktorin pviktori@redhat.com 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?
On 18.1.2018 19:16, Stephen Gallagher wrote:
On Thu, Jan 18, 2018 at 12:12 PM Petr Viktorin <pviktori@redhat.com mailto:pviktori@redhat.com> 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?
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.
On 18 January 2018 at 13:45, Matthew Miller mattdm@fedoraproject.org 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 mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Thu, Jan 18, 2018 at 1:45 PM, Matthew Miller mattdm@fedoraproject.org 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
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 ofa 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.
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 ofa 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
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.
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?
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-leave@lists.fedoraproject.org
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
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-leave@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
----- Original Message -----
From: "Pavel Raiskup" praiskup@redhat.com 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-leave@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.
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
Hi,
recommending to use %define is wrong. AFAIK our guidelines tell to use %global instead.
https://fedoraproject.org/wiki/Packaging:Guidelines#.25global_preferred_over... (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@lists.stg.fedoraproject.org
-
Adam Williamson -
Charalampos Stratakis -
Dennis Gilmore -
Florian Weimer -
James Hogarth -
Jason L Tibbitts III -
Josh Boyer -
Kevin Kofler -
Luya Tshimbalanga -
Matthew Miller -
Miro Hrončok -
Neal Gompa -
Panu Matilainen -
Pavel Raiskup -
Peter Robinson -
Petr Viktorin -
Raphael Groner -
Richard W.M. Jones -
Stephen Gallagher -
Stephen John Smoogen -
Troy Dawson