On Fri, Dec 28, 2018 at 12:38 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. > 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. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
