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
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
>> 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
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?
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org