On 2019/11/04 04:15, Michael Schroeder wrote: MS> It should work like this for SUSE's perl:
MS> If there's a minor version update (i.e. no ABI breakage), perl will be MS> configured so that it also looks into the directory of the older perl. ---- LW> If that is the correct process, it has NEVER been done LW> "correctly".
MS> That's not true. The 5.28.1 perl does look into the 5.28.0 directories, MS> it's just missing the perl(:MODULE_COMPAT_5.28.0) provides. ---- If it is done now, it wasn't done that way in the past and I was told it wouldn't be supported. Nevertheless, if the directory search path was done correctly, but the 'hidden-version' required in the object file was broken, it still would have prevented it from working: i.e.if Perl5.28.1 looked in the 5.28.0 directory and if there had been an attempt at using a module in 5.28.0, it would have not worked, as the modules there would have had the 'hidden' label, "perl(:MODULE_COMPAT_5.28.0)", which perl-5.28.1 would not have provided.
Older versions do have the provides.
--- This may be the case in tumble weed where there is supposed to be more of a smooth working of related(same 2nd field) versions working together. The last time I raise this issue was before Tumbleweed existed back in the 5.12 - 5.16 timeframe. For package gvim which can dynamically load multiple languages, it made sense to only load them if the user wanted to use a given language. However, some languages like perl were being loaded by ldd when gvim loaded. If the perl load failed, you couldn't edit any files. I submitted a patch to re-enable loading of perl on user-demand. When it the next release came out, gvim had the same problem, it didn't match some specific version, and my bugs were closed as "WON'T FIX". Note: the build-time configuration of perl is done manually and requires the maintainer to enter supported patch-releases with each release. That must also be coordinated with hidden "COMPAT" strings that need special tools to examine and set that are often only noticed as 'broken' after a distro update leaves machines requiring manual examination and repair (if they can be booted, at all). Rather than relying on 2 different places agreeing and proper configuration of the build, it seems that Achime Gratz's suggestion: On 2019/11/01 00:47, Achim Gratz wrote:
Why don't you set it up to only have it look for the major version (i.e. have everything live in .../5.28, sans the minor version part)?
would accomplish minor version compatibility and reduce the possibilities of error.
Since all of the minor version updates are required by the perl authors to be ABI compatible,
That wasn't true in the past, there were some ABI breakages in older perls.
I've heard that from suse, but have never seen it. Suse doesn't always ship what upstream ships. Could a suse patch have been the culprit? Is this something that has happened recently as they claim it shouldn't happen. Is there a bug number for this? Most importantly, was the bug filed upstream?
it only seems smart to have a release process that supports that case so that incompatibilities won't keep cropping up. I.e. it seems that configuring perl to use library versions based on the middle number would be consistent with ABI compatibility and would be the 'smart thing to do'.
Please complain with perl upstream.
I did. That's why I switched to using the middle version number for my releases and had the patch or bugfix releases point to the middle version number. I haven't seen any incompatibilities where this system was used. Does the perl product build perl as a dynamically loadable library so 3rd party programs like vim/gvim can more easily load it on user-demand? I usually try to use 'libperl.so' for the dynamic loadable and ensure it works with gvim. Is your release also used for non-tumbleweed now? Thanks! -linda -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org