On Fri, Jan 14, 2022 at 1:15 PM demerphq <demerphq@gmail.com> wrote: > On Fri, 14 Jan 2022, 20:00 Darren Duncan, <darren@darrenduncan.net> wrote: > >> On 2022-01-14 3:40 a.m., demerphq wrote: >> > On Fri, 14 Jan 2022 at 11:57, Darren Duncan wrote: >> > I feel that Perl 5.36.0 SHOULD fix its own broken behavior >> regarding stack >> > traces. >> > >> > The 5.36.0 release is a major release and is far enough away that >> DBIx::Class >> > should be able to get fixed to not rely on the broken behavior in >> time for its >> > release. >> > >> > The fix shouldn't be put off another year. If anyone depends on >> something that >> > depends on the broken behavior, they should not upgrade past 5.34.x >> until their >> > other dependencies are updated for compatibility. >> > >> > I can live with that. >> > >> > I am not really convinced the patch really does break anything however, >> we have >> > been running with the fix backported for years and we never noticed any >> issues >> > with our DBIx class code. *shrug* >> >> That's all the more reason to re-apply the bug fix to blead right away. >> >> Your experience would imply that any reliance in DBIx::Class on the >> broken >> behavior isn't in its core functionality and more in some non-core >> functionality >> or alternately just a test is broken and main code isn't. >> > > That would be my intuition, but I don't know that we use enough DBIx to be > certain. But it's extremely hard for me to understand how such broken data > could ever be truly useful. > What breaks is a test that checks what modules are loaded by DBIx::Class. The change in behavior causes it to make different conclusions as to who is loading what. I suspect this is representative for the sort of code that would be affected by this change. LeonThread Previous | Thread Next