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