On 2019/10/27 23:53, Stephan Kulow wrote:

Am 27.10.19 um 18:22 schrieb Arjen de Korte:

...

perl-Mail-SpamAssassin-Plugin-iXhash2.ppc64le: W: no-dependency-on perl-base 5.28.1
perl-Mail-SpamAssassin.ppc64le: W: no-dependency-on perl-base 5.28.1

we require the compatible perl version. You should see 'perl(:MODULE_COMPAT_5.28.1)' in the requires of the perl modules.

---- And who makes the decision as to what version(s) of perl are compatible? Some of my CPAN modules are compatible with 5.8.x -> 5.28.x.

How do modules are are only in perl express such a compat range?

How many shell scripts ship with a BASH-4.4.12-compatible tag? If a perl 5.28.1 compatible flag is required, should there not be similar for every script language?

Not sure how many versions of gVim have been broken by such requirements -- though enough to encourage users to either use "--nodeps" or try to build it themselves. For over a decade, on Windows, simply the presence or absence of 'libperl.dll' in your path was sufficient for gvim to work. Given that it is the same version of perl suse uses, why does suse make it more difficult by including a minor number in the perl version?

Isn't it also the case that applications are written on some specific version of linux? I.e. linux-5.2.18? Should applications fail to run on alternate versions of the linux kernel?

From personal experience, most versions of applications ran fine on "whatever" version of linux was underneath it -- until one day, one of the gnu libraries checked the kernel version and refused to run on such an old kernel.

Finding the source of that was a pain, yet it was a dubious tactic to encourage some people to upgrade their kernel. Disabling the check allowed that version of glibc to work for what was needed (running from a recovery disk to recover a running version of the system).

I certainly wouldn't mind all the version checks to suggest an optimal version to run on, but this seems like MS's plan to only allow newer versions of Windows to run on more modern processors. It wasn't that the older OS's didn't work in most cases, but was another heavy-handed attempt by MS to force users to upgrade to MS's latest-unstable Win-10 to bolster its market share (also before it had undergone much testing). The first of these pushes by MS was easily disabled and showed the patch to work on older processors, though the last shot in war of MS on its users has yet to be shot.

Since rpm uses shell scripts does that mean rpm should have a specific shell version embedded in order to run it it?

I seem to remember some news recently of some perl code being used to generate some part of the linux kernel. Will future versions of the kernel have a perl-compat "requirement" as well?

There's more than one reason why I generate my own version of perl and am still running perl-5.16.3. Of note, the modules I develop for CPAN have been tested up to 5.26 (have had problems generating perl for the newer 5.28 series and have yet to try the latest released version of 5.30.

So why do non-binary (pure perl) add-ons for perl need to do a specific (5.28.1) version check? Even the binary versions, *often* work -- but especially so if they are re-compiled. Perl's CPAN supports recompiling all perl modules to run on the current version, yet as the original poster would have found out, CPAN doesn't implement the version-check scheme that SUSE uses. In fact the perl authors have specifically said that the binary API's between bug-patch-versions (their 3rd version number in 5.FEATURE.BUGPATCH releases).

Even though this was communicated to the SUSE perl team, _years_ ago it has been ignored. Could you explain how it is necessary to ignore the perl team's guidance and recommendations?

Thanks! -l

On 2019/10/30 16:09, Simon Lees wrote:

On 10/31/19 9:18 AM, L A Walsh wrote:

...

From personal experience, most versions of applications ran fine on "whatever" version of linux was underneath it -- until one day, one of the gnu libraries checked the kernel version and refused to run on such an old kernel. Disabling the check allowed that version of glibc to work for what was needed (running from a recovery disk to recover a running version of the system).

More likely in some part of the library they started using a new feature in the kernel and if you had run the right code path it probably would have caused some form of crash or other issue.

----

The new code path wasn't something I needed in a rescue disk -- I just needed it to work with older code to repair the problem. Indisputably, it worked for what was needed.

If I had tried to use it as a general purpose kernel, I might have run into problems -- but the point was that it worked for what was needed, but hard coding in a check for it to fail, was guaranteed to make not work for what was needed.

In the non perl case, writing `Requires: python > 3.5.0` or `Requires: libfoo >= 1.5` is somewhat common,

If applications only put a minimum version, 90% of the problems I encountered wouldn't have been encountered. The problem is changing python > 3.5.0 to python == 3.5.0. It's the requirement not for a newer version but a specific version that has caused problems.

Worse, rpm-lint has a requirement that modules have a requirement on a specific base version rather than on the lowest one they need. Perl has that feature built into it -- which is another reason why it isn't needed at the binary level. I know the modules I've put in CPAN in the worst case have only been tested with perl's going back to 5.8.x. However I don't know that they won't work under earlier versions so I don't needlessly disable their ability to run on the older versions.

On 2019/10/31 01:03, Andreas Schwab wrote:

On Okt 30 2019, L A Walsh wrote:

...

And who makes the decision as to what version(s) of perl are compatible?

Some of my CPAN modules are compatible with 5.8.x -> 5.28.x.

You are confusing API compatibility with ABI compatibility. The binary package records ABI compatibility. For API compatibility, you have BuildRequires in the spec files.

Andreas.

----- Not at all confused. Most modules don't have a binary component or, at least, have a "pure perl" component so there is no binary that needs compatibility. That said, the perl devs have said that binary compatibility should be stable -- i.e. 5.20.0 is compatible with 5.20.9 (if not there's a bug).

For modules that didn't have a binary component 5.8 is compatible with 5.16. Even above 5.16, there's a very good chance pure perl modules are compatible. Certainly on windows, libperl.dll based on 5.8 was just as compatible as 5.12.

Disallowing it in software guarantees failure and incompatibility. It's worse if the packager refused to build a dynamically loaded shared-object (.so). If the .so is hard-linked in, then your editor is worthless unless you update your perl as well, but if it is dynamically loaded on an as needed basis, then if it doesn't load, you can still use the editor for what it is intended: editing. May not be able to run perlscripts which would be a bummer for many, but not being able to edit is clearly worse.

Having your console editor require linkage with 'X' which requires rebuilding font caches is also pretty nasty. The GUI version -- yeah, it needs X, but the console version, 'vim' shouldn't need 'x' or font selection, but on suse it was built to require both -- again, forcing the user to build their own non-broken version, assuming they could figure out how.

Yes, I submitted a bug...and even included the patch to allow separating perl out so it wasn't needed if it wasn't used -- same as it's been on windows for 20 years. The patch wasn't used and I was told that being able to edit in the console wouldn't be supported unless everything thing else, *unneeded*, was there.

On 2019/10/31 02:27, Dominique Leuenberger / DimStar wrote:

Yet, all perl modules are being installed in /ust/lib/perl5/vendor_perl/<perlversion> - and perl forgets to look in all other locations.

that alone is the reason for the perl modules to require the explicit perl version - or perl actually does not find the modules.

---- Actually, your conclusion is exactly opposite of what is so.

If perl only looked in the new location there would be no reason for a binary check. I.e. if, as you say, perl forgets to look in all other locations, that alone is a reason to NOT include a perl version in the modules because those modules with 'wrong versions' will never be found.

If perl only looks in the new location, then what possible reason would there be to force the packages to have a version in the binary.

Cheers, Dominique

Based on Dominique's observation putting versions in perl and the perl modules is redundant and can only introduce conflict or confusion as perl will only ever look in the appropriately versioned directory.

Therefor I'd like to see a change-action done to have the "requires perl version" removed from rpms and included binary objects.

On 2019/10/31 03:55, Dominique Leuenberger / DimStar wrote:

huh?

A package that installs files into /usr/lib/perl5/perl_vendor/5.28.1 only works together with perl 5.28.1 - so this package by its pure nature requires perl 5.28.1 - which is exactly what the perl_requires macro adds here.

Anything else is nonsense and makes the package broken whenever the perl version changes.

---- I think I'm not making myself clear.

When a package is generated for perl 5.28.1, the rpm will include instructions to install it under the perl-lib dir under directory 5.28.1. That would still remain. If you install perl 5.28.2, the new perl won't look in 5.28.1. That won't change.

What is happening now is that when you create the package in ADDITION to what directory it is installing into (5.28.1). The suse build process requires that the rpm also say it is only for 5.28.1, AND if there is any binary, the binary _may_ be marked to only look for a matching perl version of 5.28.1.

It is marked in 3 separate places. The first thing I point out is that 1 is enough -- the fact that it is installed in 5.28.1 means a perl built to only look in 5.28.2 won't see it -- so it is pointless to put the requirement in the rpm and in the binary.

It's like the old saying about someone having 2 clocks. The person with 1 clock always knows what time it is, but the person with 2 clocks may never know what time it is (if the 2 clocks differ by 1 second a day, which is correct?)

Say that the clock is reset automatically, once a week, because the noon bell on Saturdays has an extra tone that clocks pick up and reset themselves, but only on that day.

The person with 1 clock will tend to assume it is correct (unless it is greatly out of sync!). But the person with 2 clocks will wonder which is correct even if they vary by 1 second a day, only because they have 2 different time versions.

It could be worse if someone had 3 different time versions.

If you only have 1 version then there will be no confusion unless it is very broken. But if you have 3, you have 2 chances for one of the versions to not be set the same and either one being different will cause the program not to run (even if they were compatible!)

If you only had 1 version, then the ultimate test would be whether or not the program ran -- even if the version was *incorrect*, it's still very possible -- even _likely_ if it is pure perl (no binary) that the program will run.

Furthermore, the perl authors say that 5.28.2 will normally be compatible with 5.28.1 even if there is binary in the module. Perl can be configured where to look for its libraries -- if perl was configured to only look for modules in 5.28, and modules installed in lib/5.28 (no matter if they were 5.28.1 or 5.28.2) then it wouldn't matter -- both would run.

However, if, instead, some module was configured with 3 digits, it would fail because the digits didn't match -- even though it was compatible.

Indeed, as others have said, python only look for version >= 3.5. Not only will both 3.5.1 and 3.5.2 both work, but so would 3.6. Perl modules can be the same way, at *least* within the 3rd point-level version number.

I hope I did better in explaining what I was talking about (?).

On 2019/10/31 05:41, Dominique Leuenberger / DimStar wrote:

The dep inside the rpm is nescessary for the package to actually TELL the user that this won't work - installing files to a directory where our perl won't look for it is not going to help.

---- Ah, because perl is configured to put thing in directories like 5.16.0, 5.16.1, 5.16.2, etc.

But if perl was configured (in an extreme counter example case) to always put libs in '5', then all versions of perl5 would look there for perl and as long as the rpm said it was meant for perl5, then it would work (from an installation point of view).

Though -- more in between, if perl, like python was to only use 2 version numbers, like 5.28, and any version that started with 5.28 would end up in that directory (like 5.28.0, 5.28.3, 5.28.9...etc). From a release-configuration point of view -- as long as the rpm points to perl 5.28 as the compatible version (and directory), then that middle road should also work (because it works for python saying >=3.5 even if it is really 3.5.1 or 3.5.3, etc), right?

I.e. if it works for python, then it should work with perl -- I understand, I think, where you are coming from -- as long as both libraries and perl point to the same directory, they should work together. That should work for most people, including me, unless your requirement is that somebody's gotta be screwed and there has to be a loser, in which case we'd still have a problem, but hopefully you aren't that type of person -- that'd just be silly.

I'm fully aware the distro I'm responsible for will never match the requriements of 'all people' (in this case, likely you) - but I'm not willing to give up this dependency in the rpms to cater to your need here.

---- Are you really giving up all dependencies, or are they just being made the same as with other languages? Consider, if it is really necessary for perl, then isn't it necessary for other languages? Is that your position? Is it catering to someone's need to have the checks the same as in other languages, or is it catering to someone's need to have perl be different?

On 2019/10/31 07:11, Michael Schroeder wrote:

It should work like this for SUSE's perl:

If there's a minor version update (i.e. no ABI breakage), perl will be configured so that it also looks into the directory of the older perl.

So perl-5.28.1 should also look into the 5.28.0 directory. Also, perl-5.28.1 should provide both "perl(:MODULE_COMPAT_5.28.1)" and "perl(:MODULE_COMPAT_5.28.0)".

---- It should also be true if there was a 5.28.2 and a 5.28.3.

Now, looking at Factory's perl this doesn't seem to be true, so apparently I made a mistake when I did the 5.28.1 update.

---- If that is the correct process, it has NEVER been done "correctly". That being the case, I would take it that the process is at fault and that it lends itself toward making it difficult or impossible to get right.

Since all of the minor version updates are required by the perl authors to be ABI compatible, 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'.

With perl upstream doing major version updates this often, all of this is moot. Factory will get perl-5.30.0 in a couple of weeks, which will not be compatible to 5.28.*.

---- None of it is moot, since 5.30.1 has also been released and makes it the perfect opportunity for a switch to using 5.30 as the library directory. For purposes of dealing with 'hanging chad', or left-over extra version usage, installing symlinks for minor versions would seem to be prudent in catching any module that isn't "with the program", i.e. when 5.30.x is first installed, it would be installed with libs in 5.30, and symlinks created in each of the perl5 subdirs (dist,suse,site) for each of the subversions released to that date -- i.e. 5.30.0 => 5.30 5.30.1 => 5.30 (etc.)....

Handling minor releases is even more important for non-tumbleweed releases as they come less frequently. Do you handle both releases, or is there someone else that needs to become aware of the new directory scheme.

Also, as part of that -- there are other packages that should be built to use a shared perl library. Does the perl build put that in /usr/lib64? or is that required for each project that wants to use that shared library? That may be part of the problem with usage in programs like 'gvim'.

Cheers, Michael.

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

On 2019/11/01 00:47, Achim Gratz wrote:

Am 31.10.2019 um 15:11 schrieb Michael Schroeder:

...

If there's a minor version update (i.e. no ABI breakage), perl will be configured so that it also looks into the directory of the older perl.

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)?

---- Can I 2nd that? ^^^

Seems like an intelligent solution to me, but I've only been using perl for about 20 years, so, I might be missing something.