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