On Fri, Dec 28, 2018 at 6:46 PM Avram Lubkin <aviso@xxxxxxxxxxxxxx> wrote: > > On Fri, Dec 28, 2018 at 11:55 AM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx >> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx >> 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@xxxxxxxxxxxxxxxxxxxxxxx > > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
