https://fedoraproject.org/wiki/Changes/EnablingPythonGeneratorsByDefault
= Enabling Python Generators by default =
== Summary == This change enables the Python module dependency generator for packages that provide Python Egg/Wheel metadata by default (this was [[Changes/EnablingPythonGenerators|opt-in since Fedora 28]]).
== Owner == * Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:ngompa|Neal Gompa]] * Email: ignatenkobrain@fedoraproject.org, ngompa13@gmail.com * Release notes owner:
== Detailed Description == Please see [[Changes/EnablingPythonGenerators#Detailed_Description|detailed description from original change]] for information how it works and implemented.
In this change we will switch opt-in into opt-out.
== Benefit to Fedora == All the benefits as stated in [[Changes/EnablingPythonGenerators#Benefit_to_Fedora|original change]] will be turned on for all packages (unless they opt-out).
== Scope == * Proposal owners: Flip the switch (in python-rpm-generators) and adjust python-rpm-macros to make feature be opt-out. Send patches to packages to remove unnecessary manual-specified dependencies. * Other developers: Packagers are strongly advised to remove manually-specified python dependencies if they are set in egg/wheel metadata. * Release engineering: [https://pagure.io/releng/issue/7965 #7965] (change should be implemented before mass rebuild) * Policies and guidelines: Python Guidelines needs to be updated with instructions how to disable the feature. * Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact == Some new dependencies might be automatically added, but this is rather good because it fixes real bugs.
== How To Test == TBD
== User Experience == Users will see less number of packages with missing dependency information.
== Dependencies == None.
== Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) Owners will revert change and postpone it to next release. * Contingency deadline: Beta freeze.
== Documentation == Packaging guidelines already contain [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_automatic... information how this feature work].
This is system-wide change, at least that's what wiki says ;) On Sat, Dec 8, 2018 at 1:45 AM Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/EnablingPythonGeneratorsByDefault
= Enabling Python Generators by default =
== Summary == This change enables the Python module dependency generator for packages that provide Python Egg/Wheel metadata by default (this was [[Changes/EnablingPythonGenerators|opt-in since Fedora 28]]).
== Owner ==
- Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:ngompa|Neal Gompa]]
- Email: ignatenkobrain@fedoraproject.org, ngompa13@gmail.com
- Release notes owner:
== Detailed Description == Please see [[Changes/EnablingPythonGenerators#Detailed_Description|detailed description from original change]] for information how it works and implemented.
In this change we will switch opt-in into opt-out.
== Benefit to Fedora == All the benefits as stated in [[Changes/EnablingPythonGenerators#Benefit_to_Fedora|original change]] will be turned on for all packages (unless they opt-out).
== Scope ==
- Proposal owners: Flip the switch (in python-rpm-generators) and
adjust python-rpm-macros to make feature be opt-out. Send patches to packages to remove unnecessary manual-specified dependencies.
- Other developers: Packagers are strongly advised to remove
manually-specified python dependencies if they are set in egg/wheel metadata.
- Release engineering: [https://pagure.io/releng/issue/7965 #7965]
(change should be implemented before mass rebuild)
- Policies and guidelines: Python Guidelines needs to be updated with
instructions how to disable the feature.
- Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact == Some new dependencies might be automatically added, but this is rather good because it fixes real bugs.
== How To Test == TBD
== User Experience == Users will see less number of packages with missing dependency information.
== Dependencies == None.
== Contingency Plan ==
- Contingency mechanism: (What to do? Who will do it?) Owners will
revert change and postpone it to next release.
- Contingency deadline: Beta freeze.
== Documentation == Packaging guidelines already contain [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_automatic... information how this feature work].
-- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis _______________________________________________ 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
On Sat, Dec 8, 2018 at 4:08 AM Igor Gnatenko ignatenkobrain@fedoraproject.org wrote:
This is system-wide change, at least that's what wiki says ;)
That is correct. I should not send email after being in meetings all day. :-D
Looks like the dependency generator was turned on in rawhide. Igor has been making pull releases against packages because this is now creating duplicate requires for some packages. That would seem reasonable, but he never pushed the dependency generator to EPEL so packages which maintain a common spec file across branches require additional logic and it's creating more work instead of less work. The python-rpm-generators package doesn't even exist in EPEL. I started looking at what it would take to make it available, but the script that's used has no documentation and no tests.
I recommend we revert this to opt-in until a couple loose ends are tied up: - Tests and a readme file are created for python-rpm-generators - The functionality is made available in EPEL6 and EPEL7 (opt-in ok) (Requires python-rpm-generators RPM)
Avram
On Sat, Dec 8, 2018 at 10:15 AM Ben Cotton bcotton@redhat.com wrote:
On Sat, Dec 8, 2018 at 4:08 AM Igor Gnatenko ignatenkobrain@fedoraproject.org wrote:
This is system-wide change, at least that's what wiki says ;)
That is correct. I should not send email after being in meetings all day. :-D
-- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis _______________________________________________ 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
On Fri, Dec 28, 2018 at 11:35 AM Avram Lubkin aviso@rockhopper.net wrote:
Looks like the dependency generator was turned on in rawhide. Igor has been making pull releases against packages because this is now creating duplicate requires for some packages. That would seem reasonable, but he never pushed the dependency generator to EPEL so packages which maintain a common spec file across branches require additional logic and it's creating more work instead of less work. The python-rpm-generators package doesn't even exist in EPEL. I started looking at what it would take to make it available, but the script that's used has no documentation and no tests.
python-rpm-generators is not the real upstream for that code (rpm is). And testability would be a bit difficult because all the script does is pull stuff from python module metadata using setuptools and print it out. It's not going to exist in EPEL because in RHEL, the Python dependency generator doesn't exist at all. If we enabled it for EPEL, we'd have broken dependencies everywhere, since no RHEL Python modules would have the necessary generated dependencies. If you'd like to ask Red Hat to add it to RHEL 7, be my guest. However, I suspect they'll say no.
I recommend we revert this to opt-in until a couple loose ends are tied up:
- Tests and a readme file are created for python-rpm-generators
- The functionality is made available in EPEL6 and EPEL7 (opt-in ok) (Requires python-rpm-generators RPM)
No. This functionality is not relevant to RHEL until a version of RHEL includes it in the base. That will happen with RHEL 8, at which point EPEL8 will have the functionality automatically. That's the whole point of getting stuff like this done in Fedora first. This is why this is a *Fedora 30 Change*.
A simple way to check if you should specify manually is to check if %__pythondist_requires is undefined, like so:
%if ! %{defined __pythondist_requires} Requires: python3-modA Requires: python3-modB ... %endif
-- 真実はいつも一つ！/ Always, there's only one truth!
On Fri, Dec 28, 2018 at 11:48 AM Neal Gompa ngompa13@gmail.com wrote:
python-rpm-generators is not the real upstream for that code (rpm is). And testability would be a bit difficult because all the script does is pull stuff from python module metadata using setuptools and print it out.
So you provide test data either as external files or using the the mock Python module. This is pretty standard.
It's not going to exist in EPEL because in RHEL, the Python dependency generator doesn't exist at all. If we enabled it for EPEL, we'd have broken dependencies everywhere, since no RHEL Python modules would have the necessary generated dependencies. If you'd like to ask Red Hat to add it to RHEL 7, be my guest. However, I suspect they'll say no.
It doesn't need to be in the base, there just needs to be el6 and epel7 branches for python-rpm-generators and make it a dependency of python-rpm-macros which is also an EPEL package. This is relatively straightforward. The only difference from Fedora is maybe it should probably be opt-in instead of enabled by default.
A simple way to check if you should specify manually is to check if %__pythondist_requires is undefined, like so:
%if ! %{defined __pythondist_requires} Requires: python3-modA Requires: python3-modB ... %endif
What is the point of this then if it requires additional logic and still requires listing dependencies for EPEL? I'm happy to help with the changes for EPEL, but I think if we're going to rely on this then it should at least have tests.
Avram
You can't make it work in EPEL easily because python modules do not have pythonX.Ydist() provides.
On Fri, Dec 28, 2018 at 6:36 PM Avram Lubkin aviso@rockhopper.net wrote:
On Fri, Dec 28, 2018 at 11:48 AM Neal Gompa ngompa13@gmail.com wrote:
python-rpm-generators is not the real upstream for that code (rpm is). And testability would be a bit difficult because all the script does is pull stuff from python module metadata using setuptools and print it out.
So you provide test data either as external files or using the the mock Python module. This is pretty standard.
It's not going to exist in EPEL because in RHEL, the Python dependency generator doesn't exist at all. If we enabled it for EPEL, we'd have broken dependencies everywhere, since no RHEL Python modules would have the necessary generated dependencies. If you'd like to ask Red Hat to add it to RHEL 7, be my guest. However, I suspect they'll say no.
It doesn't need to be in the base, there just needs to be el6 and epel7 branches for python-rpm-generators and make it a dependency of python-rpm-macros which is also an EPEL package. This is relatively straightforward. The only difference from Fedora is maybe it should probably be opt-in instead of enabled by default.
A simple way to check if you should specify manually is to check if %__pythondist_requires is undefined, like so:
%if ! %{defined __pythondist_requires} Requires: python3-modA Requires: python3-modB ... %endif
What is the point of this then if it requires additional logic and still requires listing dependencies for EPEL? I'm happy to help with the changes for EPEL, but I think if we're going to rely on this then it should at least have tests.
Avram _______________________________________________ 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
On Fri, Dec 28, 2018 at 12:38 PM Igor Gnatenko < ignatenkobrain@fedoraproject.org> wrote:
You can't make it work in EPEL easily because python modules do not have pythonX.Ydist() provides.
Didn't realize that and not sure why that wasn't backported. Honestly, if we aren't going to be consistent across EPEL and Fedora when we can, then why are they even under the same umbrella?
Anyway, looks like enabling it for EPEL is a bigger task. I still don't see the point of enabling it by default in Fedora at this point. It can easily be enabled for those who want it and doesn't add work for those who it won't work for. Especially since there is no test code!
On 28. 12. 18 18:58, Avram Lubkin wrote:
On Fri, Dec 28, 2018 at 12:38 PM Igor Gnatenko <ignatenkobrain@fedoraproject.org mailto:ignatenkobrain@fedoraproject.org> wrote:
You can't make it work in EPEL easily because python modules do not have pythonX.Ydist() provides.Didn't realize that and not sure why that wasn't backported.
Because stuff like this is not usually backported to already released RHELs.
Honestly, if we aren't going to be consistent across EPEL and Fedora when we can, then why are they even under the same umbrella?
Fedora is newer than EPEL. EPEL is old. There will always be differences even if the project is under the same umbrella.
Anyway, looks like enabling it for EPEL is a bigger task. I still don't see the point of enabling it by default in Fedora at this point.
The point is to make Fedora packaging easier. Note the "Fedora" in this sentence. This will make future EL packaging easier as well, however not past ELs.
It can easily be enabled for those who want it and doesn't add work for those who it won't work for.
It is now enabled. You can use it together with manual deps to maintain a single spec across EPEL and Fedora. I don't know what exactly is such a big deal here. It can also be easily disabled if you really like to.
Especially since there is no test code!
And this is the only thing when I agree with you.
Neal, where would be the best place to add some tests for the generator? I can scratch something like [1] during next week.
[1] https://github.com/rpm-software-management/rpm-extras/blob/master/brpscripts...
On Fri, Dec 28, 2018 at 1:10 PM Miro Hrončok mhroncok@redhat.com wrote:
On 28. 12. 18 18:58, Avram Lubkin wrote:
Especially since there is no test code!
And this is the only thing when I agree with you.
Neal, where would be the best place to add some tests for the generator? I can scratch something like [1] during next week.
Tests belong in the rpm repository[1]. rpm itself uses autotest, so if you want to wire the test into the existing framework, you can. However, if we're going to have tests for dep generators, you might want to place them in a subfolder in the tests directory[2] and wire them into autotools.
[1]: https://github.com/rpm-software-management/rpm [2]: https://github.com/rpm-software-management/rpm/tree/master/tests
-- 真実はいつも一つ！/ Always, there's only one truth!
On 28. 12. 18 22:10, Neal Gompa wrote:
On Fri, Dec 28, 2018 at 1:10 PM Miro Hrončok mhroncok@redhat.com wrote:
On 28. 12. 18 18:58, Avram Lubkin wrote:
Especially since there is no test code!
And this is the only thing when I agree with you.
Neal, where would be the best place to add some tests for the generator? I can scratch something like [1] during next week.
Tests belong in the rpm repository[1]. rpm itself uses autotest, so if you want to wire the test into the existing framework, you can. However, if we're going to have tests for dep generators, you might want to place them in a subfolder in the tests directory[2] and wire them into autotools.
I can contribute tests. Tests is what I understand. But I would not dare to touch autotools, sorry.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Fri, Dec 28, 2018 at 4:12 PM Miro Hrončok mhroncok@redhat.com wrote:
On 28. 12. 18 22:10, Neal Gompa wrote:
On Fri, Dec 28, 2018 at 1:10 PM Miro Hrončok mhroncok@redhat.com wrote:
On 28. 12. 18 18:58, Avram Lubkin wrote:
Especially since there is no test code!
And this is the only thing when I agree with you.
Neal, where would be the best place to add some tests for the generator? I can scratch something like [1] during next week.
Tests belong in the rpm repository[1]. rpm itself uses autotest, so if you want to wire the test into the existing framework, you can. However, if we're going to have tests for dep generators, you might want to place them in a subfolder in the tests directory[2] and wire them into autotools.
I can contribute tests. Tests is what I understand. But I would not dare to touch autotools, sorry.
You can make a subfolder and make a test file and ask for help to wire it into autotools. I don't know how to do it either.
On Fri, Dec 28, 2018 at 7:21 PM Miro Hrončok mhroncok@redhat.com wrote:
On 28. 12. 18 18:58, Avram Lubkin wrote:
On Fri, Dec 28, 2018 at 12:38 PM Igor Gnatenko <ignatenkobrain@fedoraproject.org mailto:ignatenkobrain@fedoraproject.org> wrote:
You can't make it work in EPEL easily because python modules do not have pythonX.Ydist() provides.Didn't realize that and not sure why that wasn't backported.
Because stuff like this is not usually backported to already released RHELs.
Honestly, if we aren't going to be consistent across EPEL and Fedora when we can, then why are they even under the same umbrella?
Fedora is newer than EPEL. EPEL is old. There will always be differences even if the project is under the same umbrella.
Anyway, looks like enabling it for EPEL is a bigger task. I still don't see the point of enabling it by default in Fedora at this point.
The point is to make Fedora packaging easier. Note the "Fedora" in this sentence. This will make future EL packaging easier as well, however not past ELs.
It can easily be enabled for those who want it and doesn't add work for those who it won't work for.
It is now enabled. You can use it together with manual deps to maintain a single spec across EPEL and Fedora. I don't know what exactly is such a big deal here. It can also be easily disabled if you really like to.
Duplicated dependencies is a problem because rpm-md becomes larger. If we would use Requires: python%{python3_version}dist() dependencies, then RPM would merge them and it would be fine. But since we use python3-foo and python3dist(foo), it makes duplicated dependencies.
So I'm just trying to send PRs to remove such deps.
On Sat, Dec 29, 2018 at 2:04 AM Igor Gnatenko < ignatenkobrain@fedoraproject.org> wrote:
Duplicated dependencies is a problem because rpm-md becomes larger. If we would use Requires: python%{python3_version}dist() dependencies, then RPM would merge them and it would be fine. But since we use python3-foo and python3dist(foo), it makes duplicated dependencies.
An article giving instructions and creating bug reports might be a better approach. Then if there is no movement create a PR. Should save you some work and lets people do things in their own style. This is similar to what Miro has been doing with the python2 deprecation.
On Sat, Dec 29, 2018, 14:36 Avram Lubkin <aviso@rockhopper.net wrote:
On Sat, Dec 29, 2018 at 2:04 AM Igor Gnatenko < ignatenkobrain@fedoraproject.org> wrote:
Duplicated dependencies is a problem because rpm-md becomes larger. If we would use Requires: python%{python3_version}dist() dependencies, then RPM would merge them and it would be fine. But since we use python3-foo and python3dist(foo), it makes duplicated dependencies.
An article giving instructions and creating bug reports might be a better approach. Then if there is no movement create a PR. Should save you some work and lets people do things in their own style. This is similar to what Miro has been doing with the python2 deprecation.
Removal of python2 subpackage is huge and iterative effort. Removal of duplicated Requires is not.
It won't save me or anybody else time at all. Most of the people would just like to get their package fixed instead of reading anything.
On Fri, Dec 28, 2018 at 7:06 PM Avram Lubkin aviso@rockhopper.net wrote:
On Fri, Dec 28, 2018 at 12:38 PM Igor Gnatenko ignatenkobrain@fedoraproject.org wrote:
You can't make it work in EPEL easily because python modules do not have pythonX.Ydist() provides.
Didn't realize that and not sure why that wasn't backported. Honestly, if we aren't going to be consistent across EPEL and Fedora when we can, then why are they even under the same umbrella?
Anyway, looks like enabling it for EPEL is a bigger task. I still don't see the point of enabling it by default in Fedora at this point. It can easily be enabled for those who want it and doesn't add work for those who it won't work for. Especially since there is no test code!
Well, it has been opt-in since F28[0].
Automatic dependency generator actually fixes missing requirements and/or wrong ones.
For instance, python-zeroconf was depending on `python3-six` and `python3-netaddr` while the actual and only requirement was the `python3-ifaddr`.
So it's already decided that we are going to enable them in F30+. (Change was approved by FESCo and already turned on).
And yeah, patches (to add tests) are welcome.
[0] https://fedoraproject.org/wiki/Changes/EnablingPythonGenerators
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
On Fri, Dec 28, 2018 at 11:34:02AM -0500, Avram Lubkin wrote:
Looks like the dependency generator was turned on in rawhide. Igor has been making pull releases against packages because this is now creating duplicate requires for some packages. That would seem reasonable, but he never pushed the dependency generator to EPEL so packages which maintain a common spec file across branches require additional logic and it's creating more work instead of less work. The python-rpm-generators package doesn't even exist in EPEL. I started looking at what it would take to make it available, but the script that's used has no documentation and no tests.
Well, now that this has been enabled, it is likely that there already are packages which make use of this functionality, and disabling the generator again would break them. So reverting the changes doesn't seem like a good idea. It'd also create even more chaos.
I recommend we revert this to opt-in until a couple loose ends are tied up:
- Tests and a readme file are created for python-rpm-generators
- The functionality is made available in EPEL6 and EPEL7 (opt-in ok)
(Requires python-rpm-generators RPM)
Maintaining single-spec compatibility with EPEL is the responsibility of individual package maintainers that desire that. The changes to use the generators are only done in "master", so before merging those changes into the epel branches, the maintainers have the chance to add the necessary conditionals or some other solution. (Alternatively, disabling the generators in that specific package and continuing to use the manual deps is also a valid option.)
Zbyszek
On Fri, Dec 28, 2018 at 11:55 AM Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
Well, now that this has been enabled, it is likely that there already are packages which make use of this functionality, and disabling the generator again would break them. So reverting the changes doesn't seem like a good idea. It'd also create even more chaos.
It's just been a week so I doubt the impact is very large and the fix is simply to explicitly turn on dependency generation. Igor and Neal are championing this change, so I think if they can go back and work on the missed steps, no reason to revert in rawhide, but if no one is signs up to fix it, then it's clearly not ready.
Maintaining single-spec compatibility with EPEL is the responsibility of individual package maintainers that desire that. The changes to use the generators are only done in "master", so before merging those changes into the epel branches, the maintainers have the chance to add the necessary conditionals or some other solution. (Alternatively, disabling the generators in that specific package and continuing to use the manual deps is also a valid option.)
You seen to misunderstand how a common spec works. There are no changes made between the branch merges. The purpose of this is to make it easier to maintain packages across branches so packages don't languish unnecessarily. Yes, it can be disabled per package, but isn't the point of this to save effort. Seems like it just creates more work for other people.
Avram
On Fri, Dec 28, 2018 at 11:55 AM Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
On Fri, Dec 28, 2018 at 11:34:02AM -0500, Avram Lubkin wrote:
Looks like the dependency generator was turned on in rawhide. Igor has
been
making pull releases against packages because this is now creating duplicate requires for some packages. That would seem reasonable, but he never pushed the dependency generator to EPEL so packages which maintain
a
common spec file across branches require additional logic and it's
creating
more work instead of less work. The python-rpm-generators package doesn't even exist in EPEL. I started looking at what it would take to make it available, but the script that's used has no documentation and no tests.
Well, now that this has been enabled, it is likely that there already are packages which make use of this functionality, and disabling the generator again would break them. So reverting the changes doesn't seem like a good idea. It'd also create even more chaos.
I recommend we revert this to opt-in until a couple loose ends are tied
up:
- Tests and a readme file are created for python-rpm-generators
- The functionality is made available in EPEL6 and EPEL7 (opt-in ok)
(Requires python-rpm-generators RPM)
Maintaining single-spec compatibility with EPEL is the responsibility of individual package maintainers that desire that. The changes to use the generators are only done in "master", so before merging those changes into the epel branches, the maintainers have the chance to add the necessary conditionals or some other solution. (Alternatively, disabling the generators in that specific package and continuing to use the manual deps is also a valid option.)
Zbyszek _______________________________________________ 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
On Fri, Dec 28, 2018 at 6:46 PM Avram Lubkin aviso@rockhopper.net wrote:
On Fri, Dec 28, 2018 at 11:55 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
Well, now that this has been enabled, it is likely that there already are packages which make use of this functionality, and disabling the generator again would break them. So reverting the changes doesn't seem like a good idea. It'd also create even more chaos.
It's just been a week so I doubt the impact is very large and the fix is simply to explicitly turn on dependency generation. Igor and Neal are championing this change, so I think if they can go back and work on the missed steps, no reason to revert in rawhide, but if no one is signs up to fix it, then it's clearly not ready.
Please specify what exactly you want us to fix.
Maintaining single-spec compatibility with EPEL is the responsibility of individual package maintainers that desire that. The changes to use the generators are only done in "master", so before merging those changes into the epel branches, the maintainers have the chance to add the necessary conditionals or some other solution. (Alternatively, disabling the generators in that specific package and continuing to use the manual deps is also a valid option.)
You seen to misunderstand how a common spec works. There are no changes made between the branch merges. The purpose of this is to make it easier to maintain packages across branches so packages don't languish unnecessarily. Yes, it can be disabled per package, but isn't the point of this to save effort. Seems like it just creates more work for other people.
I think it's you who misunderstand how people maintain their packages. Some people do like you describe, but other people do maintain different branches and don't blindly merge master to others.
Since this feature has been available since F28, I don't see any reason why this has to be reverted. You can have same package across all supported Fedora releases. This is **Fedora** change and if you would like to implement this feature for EPEL, but this is not something what me and/or Neal are going to do.
Moreover, it won't work there because pythonX.Ydist() Provides are missing there and it totally depends on RHEL Python's team to implement it and I have no control over there.
Avram
On Fri, Dec 28, 2018 at 11:55 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Fri, Dec 28, 2018 at 11:34:02AM -0500, Avram Lubkin wrote:
Looks like the dependency generator was turned on in rawhide. Igor has been making pull releases against packages because this is now creating duplicate requires for some packages. That would seem reasonable, but he never pushed the dependency generator to EPEL so packages which maintain a common spec file across branches require additional logic and it's creating more work instead of less work. The python-rpm-generators package doesn't even exist in EPEL. I started looking at what it would take to make it available, but the script that's used has no documentation and no tests.
Well, now that this has been enabled, it is likely that there already are packages which make use of this functionality, and disabling the generator again would break them. So reverting the changes doesn't seem like a good idea. It'd also create even more chaos.
I recommend we revert this to opt-in until a couple loose ends are tied up:
- Tests and a readme file are created for python-rpm-generators
- The functionality is made available in EPEL6 and EPEL7 (opt-in ok)
(Requires python-rpm-generators RPM)
Maintaining single-spec compatibility with EPEL is the responsibility of individual package maintainers that desire that. The changes to use the generators are only done in "master", so before merging those changes into the epel branches, the maintainers have the chance to add the necessary conditionals or some other solution. (Alternatively, disabling the generators in that specific package and continuing to use the manual deps is also a valid option.)
Zbyszek _______________________________________________ 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
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
On Fri, Dec 28, 2018 at 12:38 PM Avram Lubkin aviso@rockhopper.net wrote:
On Fri, Dec 28, 2018 at 11:55 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
Well, now that this has been enabled, it is likely that there already are packages which make use of this functionality, and disabling the generator again would break them. So reverting the changes doesn't seem like a good idea. It'd also create even more chaos.
It's just been a week so I doubt the impact is very large and the fix is simply to explicitly turn on dependency generation. Igor and Neal are championing this change, so I think if they can go back and work on the missed steps, no reason to revert in rawhide, but if no one is signs up to fix it, then it's clearly not ready.
No. This change has already been implemented in two other Linux distributions for over a decade, Fedora is just late to the party. I *know* it works well. There are a few fixes I need to make, and they'll be made because Igor and I discovered some new corner cases, but we wouldn't have found them unless we turned it on distro-wide.
Maintaining single-spec compatibility with EPEL is the responsibility of individual package maintainers that desire that. The changes to use the generators are only done in "master", so before merging those changes into the epel branches, the maintainers have the chance to add the necessary conditionals or some other solution. (Alternatively, disabling the generators in that specific package and continuing to use the manual deps is also a valid option.)
You seen to misunderstand how a common spec works. There are no changes made between the branch merges. The purpose of this is to make it easier to maintain packages across branches so packages don't languish unnecessarily. Yes, it can be disabled per package, but isn't the point of this to save effort. Seems like it just creates more work for other people.
You seem to misunderstand how this works. This change is not about EPEL. For this context, I couldn't possibly care any less about EPEL. If you are maintaining common specs across distributions, it is *your* responsibility to account for the differences in the distributions. Not mine. I gave you advice on how to handle the change. It's up to you to implement it.
And before you think I don't care about EPEL at all, I maintain plenty of packages in EPEL. And I know how to adapt my packages to deal with changes. Heck, a good number of my packages are Fedora/Mageia/openSUSE compatible, so I know how far to go for compatibility.
This has been opt-in for several Fedora releases already. There was already a warning that this would change to be opt out in a future Fedora release in Fedora 28. The whole point of this is to make it so that this is the new baseline in Fedora.
This is *not* getting ported to EPEL unless the Red Hat Python team wants to implement the necessary pieces in RHEL to make it work.
And for what it's worth, this is why we have branches in git corresponding to release targets. If you don't want to deal with supporting a common spec, don't. Use different ones for each target.
On Fri, 7 Dec 2018 at 19:37, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/EnablingPythonGeneratorsByDefault
= Enabling Python Generators by default =
No objection on the change. Yet the "Generators" have a well established meaning in Python, which is very different than this proposal. Python Generators have been "enabled" since Python-2.4.
Maybe the proposal can be renamed.
Best, Orcan
On 12/30/18 12:26 AM, Orcan Ogetbil wrote:
On Fri, 7 Dec 2018 at 19:37, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/EnablingPythonGeneratorsByDefault
= Enabling Python Generators by default =
No objection on the change. Yet the "Generators" have a well established meaning in Python, which is very different than this proposal. Python Generators have been "enabled" since Python-2.4.
Maybe the proposal can be renamed.
Yup, it's not the best of names in the Python context. Also on that note: a change is hardly a self-contained one when it affects hundreds of Python packages.
- Panu -
On Wed, Jan 2, 2019 at 5:30 AM Panu Matilainen pmatilai@redhat.com wrote:
On 12/30/18 12:26 AM, Orcan Ogetbil wrote:
On Fri, 7 Dec 2018 at 19:37, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/EnablingPythonGeneratorsByDefault
= Enabling Python Generators by default =
No objection on the change. Yet the "Generators" have a well established meaning in Python, which is very different than this proposal. Python Generators have been "enabled" since Python-2.4.
Maybe the proposal can be renamed.
Yup, it's not the best of names in the Python context. Also on that note: a change is hardly a self-contained one when it affects hundreds of Python packages.
It's marked as a system-wide change in the wiki. It was accidentally sent to the ML as a self-contained one.
-
Avram Lubkin -
Ben Cotton -
Igor Gnatenko -
Miro Hrončok -
Neal Gompa -
Orcan Ogetbil -
Panu Matilainen -
Zbigniew Jędrzejewski-Szmek