On 10/31/19 9:18 AM, L A Walsh wrote:
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).
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.
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?
Normally in this case we take the opposite "pessimistic" approach and limit ourselves to using a smaller subset of shell features that we know will be available regardless of which shell is being used. In the non perl case, writing `Requires: python > 3.5.0` or `Requires: libfoo >= 1.5` is somewhat common, but its more something that's done to mark packages as unresolvable on obs rather then failing to build. As an example I'm guessing there are very few places where we have python >= 3.2 as an example because its reasonable to assume that all the distro's people care about have atleast that version of python. It's only really important for libraries where we ship multiple versions. Cheers -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B