On Fri, Dec 28, 2018 at 11:55 AM Zbigniew Jędrzejewski-Szmek < zbys...@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 < zbys...@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-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
