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