Perl binary API compat between versions?

[p5pRT]

Migrated from rt.perl.org#117015 (status was 'resolved')

Searchable as RT117015$

[p5pRT]

From perl-diddler@tlinx.org

Created by perl-diddler@tlinx.org

I ran into a problem with my distro recently where I wanted to upgrade to perl 5.16.X\, (from 5.14.x) but wasn't able to due to changes in open SuSE in their 12.1 release.

It turns out\, that they now link various files for their scripting with a specific version of perl (not >=).

There reason was that perl's binary API isn't stable enough so they can't easily allow the user to upgrade their perl on their machine as it will be incompat with previous perls.

It didn't matter how many scripts they broke by not allowing this -- all that matters is their new policies. I havea fair number of Perl scripts that do automated tasks on my system. These are run by root or other login's as necessary\, so if I upgrade my system's perl\, it needs to be in a standard location.

Problem is that Suse (or specific individuals on the list) is(are) claiming perl as part of the system base and they cannot allow a user to upgrade their system's perl due to the binary API changes.

So what's the scoop? To enforce this various other binaries on the system do run-time checks or load-time checks for specific versions of perl (as well any perl-using rpm having a reliance on a specific (not a minimum) version of perl. For example SuSE 12.1 was built with perl 5.14.\. When I wanted to upgrade to perl 5.16\, I wasn't allowed to unless I upgraded my system to 12.2 (for 5.16.1) or the unreleased Factory (12.3) for 5.16.2.

  As you may notice in this bug report\, it's running with 5.16.2 -- I pulled in some packages from 12.3 that AFAIK\, didn't have a need for perl\, but some had dependencies that caused perl to be pulled in on an autodependency list.

The new version only included /usr/lib/perl5/\<.../5.16.2/...> in it's lib path -- not 5.16.1 let alone 5.14.0. I had well over 1000 modules suddenly go missing (fixed with cp -alu \<..16.1/*> \<..16.2/.>.

Of course by doing so\, I am completely unsupported\, but since several system scripts stopped working due to missing CPAN deps.

Is the perl ABI really that unstable that venders have to lock the version now or is SuSE being overreactive? I've been told that I've just "been lucky" for the past 10-15 years being able to self-upgrade parts of my open-source distribution (*cough*)....

If this is a truely a problem\, then something needs to change -- as distros are making all but impossible to upgrade parts of them -- and this is getting worse as they move towards being able to qualify for 'trusted boot' signing certs from MS.

Since I have reported this through my distro and have been told it's perl's fault -- talk to them. I'm writing this -- what needs to be fixed/what needs to happen for this not to happen? (I had to recompile vim just to edit files -- since the previous version was hard-linked with perl-5.14.xx. I suggested a dynamic load of perl.so\, which seems to work on windows -- but at least allows the primary function of editing to continue if perl can't be loaded. They asked for a patch -- gave em one. They ignored it (big surprise!)..

If this is a problem\, it needs to be fixed. They claim it's caused problems (but also haven't shared any bugid's) and trying to query for perl-version related probs\, wasn't able find any in their DB.

Ideas? Fixes?

Is perl really that different between versions that distro's feel they have to hard-code the perl version into dependencies concerning perl? It seems a CPAN rebuild doesn't work for them.

If this is the case\, is there any chance of firming up the API or having it not change so radically between versions? I.e. it doesn't work for me (or likely other perl-devs) to have their system version of perl "locked" by distros' due to instability.

Perl Info

``` Flags: category=core severity=medium This perlbug was built using Perl 5.16.1 - Mon Sep 10 13:51:31 UTC 2012 It is being executed now by Perl 5.16.2 - Fri Feb 15 01:12:05 UTC 2013. Site configuration information for perl 5.16.2: Configured by abuild at Fri Feb 15 01:12:05 UTC 2013. Summary of my perl5 (revision 5 version 16 subversion 2) configuration: Platform: osname=linux, osvers=3.4.6-2.10-default, archname=x86_64-linux-thread-multi uname='linux build34 3.4.6-2.10-default #1 smp thu jul 26 09:36:26 utc 2012 (641c197) x86_64 x86_64 x86_64 gnulinux ' config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Dd_dbm_open -Duseshrplib=true -Doptimize=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe -Accflags=-DPERL_USE_SAFE_PUTENV -Dotherlibdirs=/usr/lib/perl5/site_perl' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe', cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector' ccversion='', gccversion='4.7.2 20130108 [gcc-4_7-branch revision 195012]', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib64 -fstack-protector' libpth=/lib64 /usr/lib64 /usr/local/lib64 libs=-lm -ldl -lcrypt -lpthread perllibs=-lm -ldl -lcrypt -lpthread libc=/lib64/libc-2.17.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.17' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.16.2/x86_64-linux-thread-multi/CORE' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib64 -fstack-protector' Locally applied patches: @INC for perl 5.16.2: /home/law/bin/lib /usr/lib/perl5/site_perl/5.16.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.16.2 /usr/lib/perl5/vendor_perl/5.16.2/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.16.2 /usr/lib/perl5/5.16.2/x86_64-linux-thread-multi /usr/lib/perl5/5.16.2 /usr/lib/perl5/site_perl/5.16.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.16.2 /usr/lib/perl5/site_perl . Environment for perl 5.16.2: HOME=/home/law LANG=en_US.UTF-8 LANGUAGE (unset) LC_COLLATE=C LC_CTYPE=en_US.UTF-8 LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=.:/sbin:/usr/local/sbin:/home/law/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/opt/dell/srvadmin/bin:/usr/sbin:/home/law/bin/lib:/etc/local/func_lib:/home/law/lib PERL5OPT=-CSA -I/home/law/bin/lib PERL_BADLANG (unset) SHELL=/bin/bash ```

[p5pRT]

From @jkeenan

On Sun Mar 03 00​:01​:31 2013\, LAWalsh wrote​:

This is a bug report for perl from perl-diddler@​tlinx.org\, generated with the help of perlbug 1.39 running under perl 5.16.2.

----------------------------------------------------------------- [Please describe your issue here]

I ran into a problem with my distro recently where I wanted to upgrade to perl 5.16.X\, (from 5.14.x) but wasn't able to due to changes in open SuSE in their 12.1 release.

It turns out\, that they now link various files for their scripting with a specific version of perl (not >=).

There reason was that perl's binary API isn't stable enough so they can't easily allow the user to upgrade their perl on their machine as it will be incompat with previous perls.

It didn't matter how many scripts they broke by not allowing this -- all that matters is their new policies. I havea fair number of Perl scripts that do automated tasks on my system. These are run by root or other login's as necessary\, so if I upgrade my system's perl\, it needs to be in a standard location.

Problem is that Suse (or specific individuals on the list) is(are) claiming perl as part of the system base and they cannot allow a user to upgrade their system's perl due to the binary API changes.

I believe that many people take the approach that ...

"The version of perl which your vendor (SUSE\, in this case) supplies -- typically as /usr/bin/perl -- is for the *vendor's* use. The vendor is entitled to use it to run programs that come as part of their distribution. You\, the customer\, are permitted to use that\, but if your own needs require you to make heavy use of CPAN distributions or to periodically upgrade perl to a new major version\, then you are better off building your own perl from source or getting a release tarball from perl.org and installing perl in some place like /usr/local/bin/perl.

"In other words\, rely on the system perl for the system's needs. Rely on your perl for your needs."

If you take this approach\, you should not have to worry much about what SUSE or people on SUSE mailing lists say.

Thank you very much. Jim Keenan

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @Leont

On Sun\, Mar 3\, 2013 at 9​:01 AM\, Linda Walsh \perlbug\-followup@&#8203;perl\.org wrote​:

Is the perl ABI really that unstable that venders have to lock the version now or is SuSE being overreactive? I've been told that I've just "been lucky" for the past 10-15 years being able to self-upgrade parts of my open-source distribution (*cough*)....

Yes it is\, mostly because various structs change internally. Perl has a high degree of source compatibility between versions\, but that's good enough

If this is a truely a problem\, then something needs to change -- as distros are making all but impossible to upgrade parts of them -- and this is getting worse as they move towards being able to qualify for 'trusted boot' signing certs from MS.

No\, it doesn't. Binary compatibility is sometimes hard and at other times simply impossible if we can't to continue improve perl. It's not worth the cost.

If this is the case\, is there any chance of firming up the API or having it not change so radically between versions?

The API is quite stable.

it doesn't work for me (or likely other perl-devs) to have their system version of perl "locked" by distros' due to instability.

Have you tried perlbrew? It's quite awesome.

Leon

[p5pRT]

From @iabyn

On Sun\, Mar 03\, 2013 at 03​:41​:17PM +0100\, Leon Timmermans wrote​:

On Sun\, Mar 3\, 2013 at 9​:01 AM\, Linda Walsh \perlbug\-followup@&#8203;perl\.org wrote​: No\, it doesn't. Binary compatibility is sometimes hard and at other times simply impossible if we can't to continue improve perl. It's not worth the cost.

And just to be clear\, we guarantee binary compatibility across minor versions\, but not across major versions.

So an XS module compiled under 5.14.1 will continue working if the installed perl is upgraded to 5.14.3\, but not if to 5.16.0​: it will need to be recompiled then.

(There used to be a mechanism in place to try and provide binary compatibility across major releases\, but it worked by turning all structure accesses for XS code into function calls. Which slows things down a lot. And still didn't guarantee binary compatibility.)

-- In economics\, the exam questions are the same every year. They just change the answers.

[p5pRT]

From perl-diddler@tlinx.org

On Sun Mar 03 06​:00​:55 2013\, jkeenan wrote​:

---

typically as /usr/bin/perl -- is for the *vendor's* use.

perl.org and installing perl in some place like /usr/local/bin/perl.

---

That's a bit the rub.

My perl commands are the way my system does it's system administration and have been doing so for longer than their usage of perl to do system administration.

At one point things were fine when they mostly did things in shell or C for their stuff\, but now they are discovering perl and taking it over..

I expect the system utils... bind/named\, squid\, fsbackups\, daily snapshots of the user's home disk that are mounted so users see multiple versions available in windows... all of those things require that the default perl be used.

When sendmail invokes local delivery\, it wouldn't be prudent to try to invoke some non-system version of utils. My scripts/utilities often end up going into /usr/bin.

[p5pRT]

From perl-diddler@tlinx.org

On Sun Mar 03 06​:42​:04 2013\, LeonT wrote​:

Have you tried perlbrew? It's quite awesome.

I did... caused complete chaos\, when root and daemon processes went to execute my scripts.

It took me a bit of time to figure out why none of my changes were working. (Suse dropped in scripts to automatically move user perl and system package development into their home directories starting 12.1\, so if you expected your changes to be used by the rest of the system processes\, you got a nice surprise.

[p5pRT]

From perl-diddler@tlinx.org

On Sun Mar 03 11​:05​:11 2013\, davem wrote​:

And just to be clear\, we guarantee binary compatibility across minor versions\, but not across major versions.

So an XS module compiled under 5.14.1 will continue working if the installed perl is upgraded to 5.14.3\, but not if to 5.16.0​: it will need to be recompiled then.

---

I think this is where I have accidently tended to be safe. I'd include the libs from the last previous version whether it was minor or major.

however\, at the first sign of a problem\, (or often\, regardless\, after a few days on a major release\, I'd often do a rebuild all in cpan to take advantage of the newer version's optimizations and features)...

Most of my perl stuff didn't have binary interfaces\, but some use libs that have such. So various "litmus tests" of working/none working become pretty obvious pretty quickly if a recompile of all modules is needed.

I think that's the most likely reason my upgrading my system's perl above the distro's level\, has worked over the years is a tendency towards recompiling and usually upgrading cpan module to the version that's currently working with the current compiler.

The problem has arisen with suse because they tying non-perl utils with specific\, minor perl modules. Most recently\, when they upgradeed to 5.16.2 from 5.16.1\, (or 5.16.0)\, they refused to include the previous minor paths.

It *used* to be the case (before SuSE 12.1 (~ 1-1.5 years old)\, that they included their previous release in the lib path -- now they've stopped this and only include the current. To them\, perl 5.16.{0\,1\,2} 12.2+12.3 all had incompat library paths. Trying to load 'vim' wouldn't work after a minor update because it looks for the exact version.

FWIW\, I got around various of these probs by recompiling gvim to use dynamic load of perl.so == if they dynamic load works\, it will be there\, else you just have an editor. I generally recompile their perl anyway and turn on optimization...though haven't been able to generate a full perl since 12.1 came out last spring due to problems in the 'db' calls... eventually gave up and gen my perl w/o the db calls cuz I couldn't find any 'db's on the net to see if *their* version could actually read/write it.

I.e. I wanted to verify that their version actually was able to read/write existing db files. When I couldn't find any usage of such. I gave up and figured it wasn't that important for me on my system.

They don't support user's building rpms on their own systems anymore -- in fact they don't support building rpms on a virgin system that has all of their factory-fresh development rpms installed.

Anyway... they seem to be under the impression that even minor releases between 16.1 and 16.2 require enforcing a complete lockin (rpm's have specific versions of perl required\, and runtime libraries look for specific version strings of various libraries to run (perl's not the only victim here) -- but it's traditionally been a way to write scripts to help manage and administer the system.

From my perspective\, if their system programs need a special\, fixed version of a library or util\, they should put it in a versioned directory and refer to it by version. For some reason they don't want to do that -- and that's partly RPM's fault -- as perl5.16.2's spec is written to be incompatible with perl5.16.1 and replaces it.

MS solved this by allowing side-by-side libs and applications to link to the version they need -- which they finally got working in Vista/Win7. They used to have non-versioned runtime libs before Vista\, creating DLL-hell as there could be only 1 copy of a lib in memory -- and if it wasn't the right version\, you were SOL.

Bottom line -- from my perspective\, is that I have root and other users running my scripts to manage the system.

(There used to be a mechanism in place to try and provide binary compatibility across major releases\, but it worked by turning all structure accesses for XS code into function calls. Which slows things down a lot. And still didn't guarantee binary compatibility.)

---

Was that done dynamically if the version numbers differed\, or did it always do the indirect call? I.e. if the loader could check for version matching\, calls could be patched at load time of a module to use direct access or the slower indirect access for older versions.

Similarly\, (maybe?)\, in the linux kernel when tracing is active\, it makes out-of-band calls\, but when tracing is compiled in and deactivated\, those OOB calls are NOP'ed out and cause nearly zero time effect.

FWIW though -- they aren't even assuming that minor versions are compat. Maybe that needs to be communicated more clearly somewhere. Is there a document I can point them at?

Thanks!

(the microsoftization of linux is proving quite painful)...

[p5pRT]

From @bulk88

On Sun Mar 03 14​:06​:49 2013\, LAWalsh wrote​:

From my perspective\, if their system programs need a special\, fixed version of a library or util\, they should put it in a versioned directory and refer to it by version. For some reason they don't want to do that -- and that's partly RPM's fault -- as perl5.16.2's spec is written to be incompatible with perl5.16.1 and replaces it.

MS solved this by allowing side-by-side libs and applications to link to the version they need -- which they finally got working in Vista/Win7. They used to have non-versioned runtime libs before Vista\, creating DLL-hell as there could be only 1 copy of a lib in memory -- and if it wasn't the right version\, you were SOL.

Side by side often does NOT work in practice. A C++ object/pointer is created from 1 version of a DLL is passed to the other side by side DLL with the same name. But the 2 DLLs have different struct layouts of the C++ object or of enums. Since the class in both DLLs isn't 100% virtual methods\, a non-virtual method from DLL Ver A will assume this * has Ver A's struct layout\, while the this * actually has Ver B's struct layout. A crash or non-crash bugs (resource leaks\, flags dont have any affect) is the result. Only very carefully designed C++ code won't expose any of the internal/from another DLL classes in the public interface of the parent class.

(There used to be a mechanism in place to try and provide binary compatibility across major releases\, but it worked by turning all structure accesses for XS code into function calls. Which slows things down a lot. And still didn't guarantee binary compatibility.) -----

Was that done dynamically if the version numbers differed\, or did it always do the indirect call? I.e. if the loader could check for version matching\, calls could be patched at load time of a module to use direct access or the slower indirect access for older versions.

You always call a *portable* C function\, AFAIK the function returns the * to the var (not a copy of the var) in the interp struct. The accessor function calls caused bad code generation since the compiler will reread all non auto vars again after the call\, since the compiler can't know what malloced data the accessor function changed\, if any. Due to Perl's current rapid release policy and maintenance patch policies\, ABI changes in minor versions are not necessary anymore. New or radically redesigned (internally) features just dont get added anymore like they did in 5.8. If the interp ABI compatibility system is ever reintroduced (not likely)\, I would suggest a const table of offsets to the members in the interp library\, and a "*(SV ***)(char*)my_perl+PL_ginterpoffsets[ABI_STACK_SP]" for "PL_stack_sp".

Similarly\, (maybe?)\, in the linux kernel when tracing is active\, it makes out-of-band calls\, but when tracing is compiled in and deactivated\, those OOB calls are NOP'ed out and cause nearly zero time effect.

I can't think of an analogous feature on Windows. You are describing a JITer\, but ELF SO loader is a JITer.

FWIW though -- they aren't even assuming that minor versions are compat. Maybe that needs to be communicated more clearly somewhere. Is there a document I can point them at?

Can someone explain what the *technical* complaint or feature request here is?

Are some vendor linux perl scripts in pure perl hard coded to check $^V/$]? Or are the vendor Perls "XS_VERSION_BOOTCHECK;" and "XS_APIVERSION_BOOTCHECK;" modified to not allow forward compatibility to newer minor releases (and when upgrading the perl to a newer minor perl\, all existing XS libs won't load)? Or are absolute versioned paths to perl baked into the OS in C or on shebangs (why wouldn't symlinks fix this?)? Or I want an XS lib compiled with 5.12.4 to load into a 5.16.1 process (change the current policy so major versions are compatible)?

-- bulk88 ~ bulk88 at hotmail.com

[p5pRT]

From perl-diddler@tlinx.org

On Sun Mar 03 17​:00​:22 2013\, bulk88 wrote​:

Can someone explain what the *technical* complaint or feature request here is?

Are some vendor linux perl scripts in pure perl hard coded to check $^V/$]? Or are the vendor Perls "XS_VERSION_BOOTCHECK;" and "XS_APIVERSION_BOOTCHECK;" modified to not allow forward compatibility to newer minor releases

---

Different mechanism are used in different place to provide redundant checks for users who might try to get around the ban.

1) rpm checks​:

rpm -V yast2-perl-bindings Unsatisfied dependencies for yast2-perl-bindings-2.19.2-1.1.2.x86_64​:   perl = 5.16.0 is needed by (installed) yast2-perl-bindings-2.19.2-1.1.2.x86_64

2) run-time checks in some programs​:

gvim Perl API version v5.14.0 of VI does not match v5.16.0.

3) modifications of the INC path to exclude the current perl version​:

yast reipl Can't locate strict.pm in @​INC (@​INC contains​: /y2update/modules /home/law/.yast2/modules /usr/share/YaST2/modules /home/law/bin/lib /usr/lib/perl5/site_perl/5.16.1/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.16.1 /usr/lib/perl5/vendor_perl/5.16.1/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.16.1 /usr/lib/perl5/5.16.1/x86_64-linux-thread-multi /usr/lib/perl5/5.16.1 /usr/lib/perl5/site_perl/5.16.1/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.16.1 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.16.0/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.16.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/site_perl .) at /usr/share/YaST2/modules/URLRecode.pm line 15. BEGIN failed--compilation aborted at /usr/share/YaST2/modules/URLRecode.pm line 15. Compilation failed in require. BEGIN failed--compilation aborted. perl -V perl -V Summary of my perl5 (revision 5 version 16 subversion 2) configuration​: ....   @​INC​:   /home/law/bin/lib   /usr/lib/perl5/site_perl/5.16.2/x86_64-linux-thread-multi   /usr/lib/perl5/site_perl/5.16.2   /usr/lib/perl5/vendor_perl/5.16.2/x86_64-linux-thread-multi   /usr/lib/perl5/vendor_perl/5.16.2   /usr/lib/perl5/5.16.2/x86_64-linux-thread-multi   /usr/lib/perl5/5.16.2   /usr/lib/perl5/site_perl/5.16.2/x86_64-linux-thread-multi   /usr/lib/perl5/site_perl/5.16.2   /usr/lib/perl5/site_perl   .

There may be other methods\, but those are 3 I've encountered.

[p5pRT]

From @tux

On Mon\, 04 Mar 2013 01​:20​:56 -0800\, "Linda Walsh via RT" \perlbug\-followup@&#8203;perl\.org wrote​:

On Sun Mar 03 17​:00​:22 2013\, bulk88 wrote​:

Can someone explain what the *technical* complaint or feature request here is?

Are some vendor linux perl scripts in pure perl hard coded to check $^V/$]? Or are the vendor Perls "XS_VERSION_BOOTCHECK;" and "XS_APIVERSION_BOOTCHECK;" modified to not allow forward compatibility to newer minor releases ---- Different mechanism are used in different place to provide redundant checks for users who might try to get around the ban.

I run openSUSE since version 7 and never ran into the trouble you encounter.

For my personal stuff I only use system-perl to verify that my CPAN modules work with it before I release. For all other perl work I have my own installations (not with perlbrew). My main perl is /pro/bin/perl and I have over a 100 other versions on my USB disk.

My system perl is not the perl installed from the main SUSE repo\, but from the languages perl repository​: http​://download.opensuse.org/repositories/devel​:/languages​:/perl/openSUSE_12.2

(change the release number to match your distribution)

# zypper ar --rfresh http​://… perl-12.2 # zypper ref # yast2 sw_single

  -> View repositories -> Choose perl-12.2 -> Switch system packages

# zypper ve

1) rpm checks​:

rpm -V yast2-perl-bindings

Not installed. Never needed those

Unsatisfied dependencies for yast2-perl-bindings-2.19.2-1.1.2.x86_64​: perl = 5.16.0 is needed by (installed) yast2-perl-bindings-2.19.2-1.1.2.x86_64

2) run-time checks in some programs​:

gvim Perl API version v5.14.0 of VI does not match v5.16.0.

gvim-7.3.566-1.5.1.i586 runs flawless on my laptop. Though I must admit I seldom use it​: My editor of choice is elvis\, which I build from source

3) modifications of the INC path to exclude the current perl version​:

yast reipl

Config 'root' not found. No such client module reipl The search path follows. It does not include the current directory.   /y2update/clients   /home/merijn/.yast2/clients   /usr/share/YaST2/clients

so I guess I never needed that one either

# zypper ve Loading repository data... Reading installed packages...

Dependencies of all installed packages are satisfied. # uname -a Linux 3.4.28-2.20-desktop #1 SMP PREEMPT Tue Jan 29 16​:51​:37 UTC 2013 (143156b) i686 i686 i386 GNU/Linux # /usr/bin/perl -V​:archname\|version archname='i586-linux-thread-multi'; version='5.16.0';

-- H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/ using perl5.00307 .. 5.17 porting perl5 on HP-UX\, AIX\, and openSUSE http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/ http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

[p5pRT]

From perl-diddler@tlinx.org

On Mon Mar 04 02​:08​:49 2013\, hmbrand wrote​:

For my personal stuff I only use system-perl to verify that my CPAN modules work with it before I release. For all other perl work I have my own installations (not with perlbrew). My main perl is /pro/bin/perl and I have over a 100 other versions on my USB disk.

My system perl is not the perl installed from the main SUSE repo\, but from the languages perl repository​:

http​://download.opensuse.org/repositories/devel​:/languages​:/perl/openSUSE_12.2

---

  ^^^^ right there is the problem. I am running on openSUSE 12.1.

It shipped with perl-5.14 -- and much trouble can result if it is upgraded.

(change the release number to match your distribution)

# zypper ar --rfresh http​://… perl-12.2 # zypper ref # yast2 sw_single

-> View repositories -> Choose perl-12.2 -> Switch system packages

# zypper ve

1) rpm checks​:

rpm -V yast2-perl-bindings

Not installed. Never needed those

---

  Most of suse's yast/yast2 is written in perl\, so it's hard to run their sys-admin programs w/o it\, though rpm doesn't need it! ;-)

Unsatisfied dependencies for yast2-perl-bindings-2.19.2- 1.1.2.x86_64​: perl = 5.16.0 is needed by (installed) yast2-perl-bindings-2.19.2-1.1.2.x86_64

2) run-time checks in some programs​:

gvim Perl API version v5.14.0 of VI does not match v5.16.0.

gvim-7.3.566-1.5.1.i586 runs flawless on my laptop. Though I must admit I seldom use it​: My editor of choice is elvis\, which I build from source

---

  I bet you it does run fine. It requires 5.16 and you are running suse 12.2 which comes with 5.16.

  I had to reinstall the gvim from my current distro to reproduce the error message above. the gvim I have\, gvim-7.3.785-1.6.x86_64 runs just fine -- but then I built-it and perl from the rpms (perl w/o the dbm routines\, which won't build on my machine -- haven't since last summer).

3) modifications of the INC path to exclude the current perl version​:

yast reipl

Config 'root' not found. No such client module reipl The search path follows. It does not include the current directory. /y2update/clients /home/merijn/.yast2/clients /usr/share/YaST2/clients

so I guess I never needed that one either

---

If you don't run yast\, you probably aren't going to run it's modules.

Many of the modules use python now -- they've been moving away from perl for the past few years\, at least.

# zypper ve Loading repository data... Reading installed packages...

Dependencies of all installed packages are satisfied. # uname -a Linux 3.4.28-2.20-desktop #1 SMP PREEMPT Tue Jan 29 16​:51​:37 UTC 2013 (143156b) i686 i686 i386 GNU/Linux

# /usr/bin/perl -V​:archname\|version archname='i586-linux-thread-multi'; version='5.16.0';

---

5.16.0 is the version that comes with 12.2\, so you're fine.

uname -a Linux Ishtar 3.8.1-Isht-Van #6 SMP PREEMPT Fri Mar 1 20​:29​:32 PST 2013 x86_64 x86_64 x86_64 GNU/Linux

---

I tend to build my own products from sources and run newer versions of those products that are important to me...
kernel\, and perl being on that list...

Been doing so since before I was on suse because vendors optimized for i386 (Redhat at the time)\, or pentium's (suse).

The point is not about whether or not I can get around it\, but the fact that suse is doing it in the first place when it doesn't seem necessary\, but the claim it is due to perl's policies. Personally\, I think it is more Suse's problem than perl's\, but what I think isn't important. What's important is to gather sufficient evidence and or input from the perl developers to convince (if that is possible)\, to abandon their restrictive practices. But given their move toward tivoization of the platform\, it may be a lost cause.

[p5pRT]

From @doughera88

On Sun\, 3 Mar 2013\, Dave Mitchell wrote​:

On Sun\, Mar 03\, 2013 at 03​:41​:17PM +0100\, Leon Timmermans wrote​:

On Sun\, Mar 3\, 2013 at 9​:01 AM\, Linda Walsh \perlbug\-followup@&#8203;perl\.org wrote​: No\, it doesn't. Binary compatibility is sometimes hard and at other times simply impossible if we can't to continue improve perl. It's not worth the cost.

And just to be clear\, we guarantee binary compatibility across minor versions\, but not across major versions.

So an XS module compiled under 5.14.1 will continue working if the installed perl is upgraded to 5.14.3\, but not if to 5.16.0​: it will need to be recompiled then.

More details are in the INSTALL file under the section​:

  =head1 Coexistence with earlier versions of perl 5

--   Andy Dougherty doughera@​lafayette.edu

[p5pRT]

From @doughera88

On Mon\, 4 Mar 2013\, Linda Walsh via RT wrote​:

On Sun Mar 03 17​:00​:22 2013\, bulk88 wrote​:

Can someone explain what the *technical* complaint or feature request here is?

Different mechanism are used in different place to provide redundant checks for users who might try to get around the ban.

1) rpm checks​:

rpm -V yast2-perl-bindings Unsatisfied dependencies for yast2-perl-bindings-2.19.2-1.1.2.x86_64​: perl = 5.16.0 is needed by (installed) yast2-perl-bindings-2.19.2-1.1.2.x86_64

That sounds like an error in the packaging system.

2) run-time checks in some programs​:

gvim Perl API version v5.14.0 of VI does not match v5.16.0.

Again\, if that's a system-supplied gvim\, then this sounds like an error in the packaging system.

3) modifications of the INC path to exclude the current perl version​:

That sounds truly odd. Why on earth would they exclude the current perl version but include older perl versions?

yast reipl Can't locate strict.pm in @​INC (@​INC contains​: /y2update/modules /home/law/.yast2/modules /usr/share/YaST2/modules /home/law/bin/lib /usr/lib/perl5/site_perl/5.16.1/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.16.1 /usr/lib/perl5/vendor_perl/5.16.1/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.16.1 /usr/lib/perl5/5.16.1/x86_64-linux-thread-multi /usr/lib/perl5/5.16.1 /usr/lib/perl5/site_perl/5.16.1/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.16.1 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.16.0/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.16.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/site_perl .) at /usr/share/YaST2/modules/URLRecode.pm line 15. BEGIN failed--compilation aborted at /usr/share/YaST2/modules/URLRecode.pm line 15. Compilation failed in require. BEGIN failed--compilation aborted.

I'm sorry\, but I have no idea what 'yast' or 'reipl' are\, so I have no idea what to make of this.

I'm sorry to be dense\, but I actually have no idea what specific bug in the perl5 distribution you are reporting here. I'm not claiming there's no problem\, just that I have no idea what that problem might be.

Could you please restate the problem very briefly in terms that someone not familiar with OpenSuse might be able to understand?

Thanks\,

--   Andy Dougherty doughera@​lafayette.edu

[p5pRT]

From @tux

On Mon\, 04 Mar 2013 04​:23​:49 -0800\, "Linda Walsh via RT" \perlbug\-followup@&#8203;perl\.org wrote​:

On Mon Mar 04 02​:08​:49 2013\, hmbrand wrote​:

For my personal stuff I only use system-perl to verify that my CPAN modules work with it before I release. For all other perl work I have my own installations (not with perlbrew). My main perl is /pro/bin/perl and I have over a 100 other versions on my USB disk.

My system perl is not the perl installed from the main SUSE repo\, but from the languages perl repository​:

http​://download.opensuse.org/repositories/devel​:/languages​:/perl/openSUSE_12.2 ---- ^^^^ right there is the problem. I am running on openSUSE 12.1.

As I stated just one line down​: change it! And those repo's do not ship perl itself\, just modules

It shipped with perl-5.14 -- and much trouble can result if it is upgraded.

If you want the system perl upgraded (god may know why)\, you could go from http​://software.opensuse.org/package/perl?search_term=%22perl%22 pick the 12.1 chain\, click on "Show unstable packages" and see that home​:doiggl has a 5.16.2 available for 12.1. DO NOT USE "cpan" to upgrade the system packages/modules​: you will loose consistency. Use the above URL instead. You can add the diggl repo​:

# zypper ar --refresh http​://download.opensuse.org/repositories/home​:/doiggl/openSUSE_12.1 doiggl-perl-12.1 # zypper ref # yast2 sw_single   view repositories\, choose doiggl-perl-12.1 and "Switch"

Still not the way I would interfere with system perl\, but at least now zypper/yast will try to stay consistent and follow dependencies

# zypper ve

is HIGHLY recommended after these actions

(change the release number to match your distribution)

# zypper ar --rfresh http​://… perl-12.2 # zypper ref # yast2 sw_single

-> View repositories -> Choose perl-12.2 -> Switch system packages

# zypper ve

1) rpm checks​:

rpm -V yast2-perl-bindings

Not installed. Never needed those ---- Most of suse's yast/yast2 is written in perl\, so it's hard to run their sys-admin programs w/o it\, though rpm doesn't need it! ;-)

And *what* in those scripts *needs* 5.16.x that cannot be done in 5.14.2? Remember that you are doing low-level system stuff here​: you don't want to break system setup

Unsatisfied dependencies for yast2-perl-bindings-2.19.2- 1.1.2.x86_64​: perl = 5.16.0 is needed by (installed) yast2-perl-bindings-2.19.2-1.1.2.x86_64

2) run-time checks in some programs​:

gvim Perl API version v5.14.0 of VI does not match v5.16.0.

gvim-7.3.566-1.5.1.i586 runs flawless on my laptop. Though I must admit I seldom use it​: My editor of choice is elvis\, which I build from source ---- I bet you it does run fine. It requires 5.16 and you are running suse 12.2 which comes with 5.16.

Yep :) (I also have 11.2\, 11.4\, and 12.1 systems)

 I had to reinstall the gvim from my current distro to reproduce the

error message above. the gvim I have\, gvim-7.3.785-1.6.x86_64 runs just fine -- but then I built-it and perl from the rpms (perl w/o the dbm routines\, which won't build on my machine -- haven't since last summer).

3) modifications of the INC path to exclude the current perl version​:

yast reipl

Config 'root' not found. No such client module reipl The search path follows. It does not include the current directory. /y2update/clients /home/merijn/.yast2/clients /usr/share/YaST2/clients

so I guess I never needed that one either ---- If you don't run yast\, you probably aren't going to run it's modules.

I use yast2 quite often​: e.g. it is a very easy interface if one wants to find out about version inconsistencies after OS upgrades.

Many of the modules use python now -- they've been moving away from perl for the past few years\, at least.

# zypper ve Loading repository data... Reading installed packages...

Dependencies of all installed packages are satisfied. # uname -a Linux 3.4.28-2.20-desktop #1 SMP PREEMPT Tue Jan 29 16​:51​:37 UTC 2013 (143156b) i686 i686 i386 GNU/Linux

# /usr/bin/perl -V​:archname\|version archname='i586-linux-thread-multi'; version='5.16.0'; ---- 5.16.0 is the version that comes with 12.2\, so you're fine.

No\, I run 5.16.2\, but not from /usr/bin

uname -a Linux Ishtar 3.8.1-Isht-Van #6 SMP PREEMPT Fri Mar 1 20​:29​:32 PST 2013 x86_64 x86_64 x86_64 GNU/Linux ---- I tend to build my own products from sources and run newer versions of those products that are important to me...

So\, perl is not important enough to buil;d from scratch? As said​: let the system have its own version of the truth and build whatever version of what you think important yourself OUTSIDE /usr.

I do the same for my daily set of tools​: elvis\, xterm\, tcsh\, perl\, git\, claws-mail\, xchat\, …

kernel\, and perl being on that list...

if perl is on that list\, I don't see the reason for this ticket at all

Been doing so since before I was on suse because vendors optimized for i386 (Redhat at the time)\, or pentium's (suse).

Just curious​: did you actually noticed any improvement? My reasons - next to being free to change/add/remove whatever *I* liked\, was disabling threads or enabling debugging\, not architectural optimizations.

The point is not about whether or not I can get around it\, but the fact that suse is doing it in the first place when it doesn't seem necessary\,

questionable\, but what should withhold them ? I see no harm

but the claim it is due to perl's policies. Personally\, I think it is more Suse's problem than perl's\,

Not SUSE's *problem*. It is their decision\, and not resulting in something that is less functional than the perl the community releases.

There is a BIG difference in releasing/shipping something broken\, or something restricted in updates/upgrades

but what I think isn't important. What's important is to gather sufficient evidence and or input from the perl developers to convince (if that is possible)\, to abandon their restrictive practices. But given their move toward tivoization of the platform\, it may be a lost cause.

-- H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/ using perl5.00307 .. 5.17 porting perl5 on HP-UX\, AIX\, and openSUSE http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/ http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

[p5pRT]

From perl-diddler@tlinx.org

H. Merijn Brand via RT wrote​:

http​://download.opensuse.org/repositories/devel​:/languages​:/perl/openSUSE_12.2 ---- ^^^^ right there is the problem. I am running on openSUSE 12.1.

As I stated just one line down​: change it! And those repo's do not ship perl itself\, just modules

  That's fine for the varying set of modules SuSE ships\, but the bulk of the modules that I use are from CPAN and are not included in SuSE's modules.

  The problem then becomes when those modules require updates -- they don't automatically call rpm for suse included modules -- like me\, they don't have a list of such modules\, at hand\, they can work off of\, so installing the version from CPAN becomes the standard.

  Having to maintain some special list of "downrev'ed modules from SuSE\, that I need to be sure to use vs. whatever the latest is in cpan\, isn't workable.

It shipped with perl-5.14 -- and much trouble can result if it is upgraded. If you want the system perl upgraded (god may know why)\, you could go from http​://software.opensuse.org/package/perl?search_term=%22perl%22 pick the 12.1 chain\, click on "Show unstable packages" and see that home​:doiggl has a 5.16.2 available for 12.1.

---

That wouldn't work due to all the interlock checks in 12.1 for perl 5.14.0. (regardless of the CPAN issue -- you can't upgrade perl on your system for all users (including root) -- that is the problem I am having. It was never a problem before 12.1 (i.e. been doing this since Suse 7.0....

# zypper ve

is HIGHLY recommended after these actions Won't work on my system. Too many incompats -- I would have to uninstall my LSI and Dell supplied software which take special versions of libraries -- that WORK (or have worked -- not sure about now\, I don't use them all the time) -- because they only work with some earlier version of Suse software.

Dell is currently compat with SUSE 11\, maybe (the corporate version)\, LSI is compat with maybe 12.1\, and if I try to set it up again\, OpenBox is compatible with 12.2.

They each need different libraries to run on and manage 1 suse system.

A "zypper ve" spews over a page worth of fails for the 1st question (and it has a bunch more questions after that) -- 76 problems the first of which is to either deinstall the Dell management SW or to break it.... and usually I go with break it\, and make sure it's libs are installed by hand\, though it's also broken right now because suse moved /var/run to a ram disk\, thus per-daemon directories like /var/run/tog-pegasus get destroyed each boot and the cim server can't open up /var/run/tog-pegasus/cimxml.socket -- it's from an era (pre 12.1)\, where /var/run wasn't destroyed each boot. I have yet to need to run it (usually when I need Dell service)\, so I haven't fixed the "rc" script to recreate it's necessary dirs each startup (they were created by the rpm when it was installed -- which expected the dir's to stay there).

Having to support various external utils that don't update every 6-9 months on SuSE's schedule creates external requirements that I don't have control over.

And *what* in those scripts *needs* 5.16.x that cannot be done in 5.14.2? Remember that you are doing low-level system stuff here​: you don't want to break system setup

---

  You have that question backwards.

  What do they need in 5.14.2 that can't be done in 5.16.2? I want to upgrade not downgrade.

  I would understand if I wanted to downgrade\, that there might be problems\, but usually upgrading is *generally*\, less of a problem\, provided they were not using deprecated features.

I use yast2 quite often​: e.g. it is a very easy interface if one wants to find out about version inconsistencies after OS upgrades.

---

My statement/assumption was based on your statement that you didn't ever need yast2-perl-bindings.

yast2 requires yast2-perl-bindings​: # rpm -q --whatrequires yast2-perl-bindings yast2-2.23.3-1.2.1.x86_64 yast2-storage-2.22.10-1.1.1.x86_64 yast2-ca-management-2.22.2-2.1.1.noarch yast2-dns-server-2.23.3-2.1.3.noarch yast2-country-2.22.6-2.1.2.x86_64 yast2-users-2.22.4-2.1.3.x86_64 yast2-ldap-server-2.22.2-2.1.3.x86_64 yast2-samba-server-2.22.3-2.1.1.noarch yast2-dhcp-server-2.22.0-2.1.3.noarch yast2-http-server-2.22.0-2.1.2.noarch yast2-metapackage-handler-0.8.14-5.1.2.noarch

---

If you are using yast2\, you are using yast2-perlbindings.

Linux Ishtar 3.8.1-Isht-Van #6 SMP PREEMPT Fri Mar 1 20​:29​:32 PST 2013 x86_64 x86_64 x86_64 GNU/Linux ---- I tend to build my own products from sources and run newer versions of those products that are important to me ...kernel and perl being on that list.

So\, perl is not important enough to buil;d from scratch?

---

I said it and the kernel were among the tools on the list? What gives you the impression that I don't build perl?

As said​: let the system have its own version of the truth and build whatever version of what you think important yourself OUTSIDE /usr.

---

That doesn't work -- I need to upgrade the perl that is used by the all users (especially including root) -- since I have been using perl scripts to manage my system long before yast2 required specific versions of perl (starting with 12.1).

Just curious​: did you actually noticed any improvement?

---

  More so with x586 v. Pentium-II/III optimizations -- 10-15%   Less so with x86-64... haven't done enough benchmarks to really say\,

The point is not about whether or not I can get around it\, but the fact that suse is doing it in the first place when it doesn't seem necessary\,

questionable\, but what should withhold them ? I see no harm

but the claim it is due to perl's policies. Personally\, I think it is more Suse's problem than perl's\,

Not SUSE's *problem*. It is their decision\, and not resulting in something that is less functional than the perl the community releases.

---

LESS functional --- I use that functionality and have to > 10 years.

They claim it's because of perl instabilities ... that's the point here.

I don't need a lecture on how to manage my system when it's been working fine for over a decade -- and now they want to cut down on linux's open-source flexibility due to supposed instabilities in perl (and in other ways\, that don't need mentioning here).

I have generally done system-level development\, not perl-development.

As such\, when I make changes\, I do so at the system level.

Arguably\, with today's HW\, I could do so in a VM\, but *if* I could get a reliable VM setup\, it would never give me the testing that using it everyday for my own use gives.

Suse switched to doing sterile-env build& test in the 12.x series.

That's when I started being plagued by incompat problems -- because they no longer test their systems on a fully installed Suse system.

[p5pRT]

From @doughera88

On Mon\, 4 Mar 2013\, Linda Walsh via RT wrote​:

That wouldn't work due to all the interlock checks in 12.1 for perl 5.14.0. (regardless of the CPAN issue -- you can't upgrade perl on your system for all users (including root) -- that is the problem I am having. It was never a problem before 12.1 (i.e. been doing this since Suse 7.0....

As far as I can tell\, this ticket can be closed\, since there is no bug in the perl5 distribution to resolve here. The discussion about Suse's packaging policies can\, of course\, continue.

--   Andy Dougherty doughera@​lafayette.edu

[p5pRT]

From @rurban

The issue is valid\, but I know of no other distro other than mine\, cygwin\, which does provides this feature. On cygwin I do check for broken API compat within sub releases\, but I guarantee that p5p does not test this when releasing a new subrelease.

You\, resp. upstream need to change the paths to omit the PERL_SUBVERSION\, fix installperl\, and ensure the proper naming of the libperl symlink. I did it via Policy.sh and a custom build script. The packager needs to ensure that no other changes crept in\, like hints changes\, compiler changes\, arch-specific config flags.

E.g. this is my @​INC on cygwin with a proper upgrade strategy​: i.e. ignore subrelease changes so people will not have to update all their XS modules\, load older non-arch modules.

perl -V​:   @​INC​:   /usr/lib/perl5/site_perl/5.14/i686-cygwin-threads-64int   /usr/lib/perl5/site_perl/5.14   /usr/lib/perl5/vendor_perl/5.14/i686-cygwin-threads-64int   /usr/lib/perl5/vendor_perl/5.14   /usr/lib/perl5/5.14/i686-cygwin-threads-64int   /usr/lib/perl5/5.14   /usr/lib/perl5/site_perl/5.10   /usr/lib/perl5/vendor_perl/5.10   /usr/lib/perl5/site_perl/5.8 -- Reini Urban http​://cpanel.net/ http​://www.perl-compiler.org/

[p5pRT]

From @jkeenan

On Wed Mar 06 09​:46​:02 2013\, doughera wrote​:

On Mon\, 4 Mar 2013\, Linda Walsh via RT wrote​:

As far as I can tell\, this ticket can be closed\, since there is no bug in the perl5 distribution to resolve here.

Agreed; closing.

The discussion about Suse's packaging policies can\, of course\, continue.

... but not here. It's not an appropriate subject for RT or for P5P. A mailing list for system administration or vendor/packager issues would be better.

Thank you very much. Jim Keenan

[p5pRT]

@jkeenan - Status changed from 'open' to 'resolved'

[p5pRT]

From @doughera88

On Wed\, 6 Mar 2013\, Reini Urban wrote​:

The issue is valid\, but I know of no other distro other than mine\, cygwin\, which does provides this feature. On cygwin I do check for broken API compat within sub releases\, but I guarantee that p5p does not test this when releasing a new subrelease.

Tests of the current 5.14 and 5.16 mainteance release candidates would be welcome.

--   Andy Dougherty doughera@​lafayette.edu

[p5pRT]

From @rurban

On Mar 6\, 2013\, at 8​:43 PM\, Andy Dougherty \doughera@&#8203;lafayette\.edu wrote​:

On Wed\, 6 Mar 2013\, Reini Urban wrote​:

The issue is valid\, but I know of no other distro other than mine\, cygwin\, which does provides this feature. On cygwin I do check for broken API compat within sub releases\, but I guarantee that p5p does not test this when releasing a new subrelease.

Tests of the current 5.14 and 5.16 mainteance release candidates would be welcome.

I did it for 5.14 already.

5.16 is considered too insecure to be releasable (illegal symbol and package names\, binary-safe name API)\, and therefore skipped.

[p5pRT]

From @iabyn

On Thu\, Mar 07\, 2013 at 06​:47​:19AM -0600\, Reini Urban wrote​:

5.16 is considered too insecure to be releasable (illegal symbol and package names\, binary-safe name API)\, and therefore skipped.

Considered insecure by Reini. Considered secure by everyone else. Please stop spreading unfounded FUD; c.f.​:

http​://www.nntp.perl.org/group/perl.perl5.porters/2012/10/msg193433.html http​://www.nntp.perl.org/group/perl.perl5.porters/2012/12/msg196481.html

-- Red sky at night - gerroff my land! Red sky at morning - gerroff my land!   -- old farmers' sayings #14

[p5pRT]

From perl-diddler@tlinx.org

On Thu Mar 07 07​:24​:40 2013\, davem wrote​:

http​://www.nntp.perl.org/group/perl.perl5.porters/2012/10/msg193433.html http​://www.nntp.perl.org/group/perl.perl5.porters/2012/12/msg196481.html

---

Having been in OS security for some time\, I have found that most buffer overflows are exploitable -- eventually. It's like cracking a crypto key. It's almost certainly doable\, question is how much time it will take and w/buffer overflows\, there's zilch research to backup claims of any of them being non-exploitable -- but that many are is proven.

I remember a specific find by me regarding an asymmetric change in capabilities that I tried to bring to Ted T'so attention\, who thought I was full of it. Two weeks later the entire section of code for capabilities was disabled and an emergency kernel patch was released disabling them for years due to a found exploit using sendmail (~2001). It was obvious to me it was a programming mistake that could cause unforeseen problems. That it was exploited a few weeks later was entirely unrelated to me\, though I found myself on Ted's well-connected black list after that. The messenger almost always gets shot.

[p5pRT]

From @rurban

On Thu\, Mar 7\, 2013 at 9​:15 AM\, Dave Mitchell \davem@&#8203;iabyn\.com wrote​:

On Thu\, Mar 07\, 2013 at 06​:47​:19AM -0600\, Reini Urban wrote​:

5.16 is considered too insecure to be releasable (illegal symbol and package names\, binary-safe name API)\, and therefore skipped.

Considered insecure by Reini. Considered secure by everyone else. Please stop spreading unfounded FUD; c.f.​:

http​://www.nntp.perl.org/group/perl.perl5.porters/2012/10/msg193433.html http​://www.nntp.perl.org/group/perl.perl5.porters/2012/12/msg196481.html

As far as I remember I never detailed my 5.16 concerns publicly. It were not these ptr bugs alone\, these were only a small part of the problem\, but they are already fixed now.

I thought it would be too risky\, so I brought that up at in private\, on perl5-security-report@​perl.org. With contradicting statements\, yes. I'm still persuaded that is too riscy and you and Zefram said the opposite. That's a valid disagreement\, no big deal. If you want to go forward I would recommend to contact the author for the code in question and ask him about it. In my experience so far the authors always confirmed their flaws.

But saying that I am spreading FUD is not helping us on this issue. "Everybody else" is also not quite right. I'm open to a technical discussions if you do not understand what I am worried about. -- Reini Urban http​://cpanel.net/ http​://www.perl-compiler.org/

[p5pRT]

From @iabyn

On Thu\, Mar 07\, 2013 at 03​:00​:56PM -0600\, Reini Urban wrote​:

5.16 is considered too insecure to be releasable (illegal symbol and package names\, binary-safe name API)\, and therefore skipped. [snip] I'm open to a technical discussions if you do not understand what I am worried about.

Ok. Please provide a description of a specific change of behaviour between 5.14 and 5.16\, and how in general terms it can be a security hole or be part of security escalation.

-- "Strange women lying in ponds distributing swords is no basis for a system of government. Supreme executive power derives from a mandate from the masses\, not from some farcical aquatic ceremony."   -- Dennis\, "Monty Python and the Holy Grail"

[p5pRT]

From @iabyn

On Thu\, Mar 07\, 2013 at 09​:52​:54PM +0000\, Dave Mitchell wrote​:

Ok. Please provide a description of a specific change of behaviour between 5.14 and 5.16\, and how in general terms it can be a security hole or be part of security escalation.

(not to be Cced to p5p of course).

-- Never work with children\, animals\, or actors.

[p5pRT]

From @rurban

On Thu\, Mar 7\, 2013 at 3​:54 PM\, Dave Mitchell \davem@&#8203;iabyn\.com wrote​:

On Thu\, Mar 07\, 2013 at 09​:52​:54PM +0000\, Dave Mitchell wrote​:

Ok. Please provide a description of a specific change of behaviour between 5.14 and 5.16\, and how in general terms it can be a security hole or be part of security escalation.

(not to be Cced to p5p of course).

I initially wrote yet another long email to explain my old 5.16 security concerns with allowing embedded nuls in symbol and classname\, besides the old issue by allowing them in pathnames and other strings args to syscalls.

But since I have not much to add to my initial complaint to perl5-security-report I rather posted now the patches to fix these issues altogether\, to break the rather silly security interpretation deadlock\, with the new risc that 5.18 will also be affected.

You are still saying that 5.16 is finally binary safe\, and I'm still staying that 5.16 with its binary safe names is more insecure now. Hidden payloads are now kept\, not stripped\, they are not only kept in pathnames or random strings\, they are now also kept in names\, stashes and the strtab\, which broadens the attack vector for a random exploit.

So​: * https://rt-archive.perl.org/perl5/Ticket/Display.html?id=117265   no warnings 'safesyscalls'\, fatal nul checks * https://rt-archive.perl.org/perl5/Ticket/Display.html?id=117267   no warnings 'safenames'\, fatal nul checks   Note that the patch is not complete yet\, the bless strings also needs to be checked\,   the ref op needs to print the embedded \0 and so on. * https://rt.cpan.org/Ticket/Display.html?id=84120 classnames not nul-safe

Much more nul-names in modules and introspection dumpers need to be fixed later on to use qq quoted strings instead of single-q '' strings in printed names and syscall args. I leave that p5p to decide to keep binary name safety or deprecate it. (my preference)

I would be happy to fix the security issues by enabling warnings. Technically use strict 'syms' would fit better\, but the infrastructure of warnings fits better to these problems. no warnings 'severe'; will turn off all severe warnings. -- Reini Urban http​://cpanel.net/ http​://www.perl-compiler.org/

[p5pRT]

From @iabyn

On Thu\, Mar 21\, 2013 at 02​:43​:28PM -0500\, Reini Urban wrote​:

On Thu\, Mar 7\, 2013 at 3​:54 PM\, Dave Mitchell \davem@&#8203;iabyn\.com wrote​:

On Thu\, Mar 07\, 2013 at 09​:52​:54PM +0000\, Dave Mitchell wrote​:

Ok. Please provide a description of a specific change of behaviour between 5.14 and 5.16\, and how in general terms it can be a security hole or be part of security escalation.

I initially wrote yet another long email to explain my old 5.16 security concerns with allowing embedded nuls in symbol and classname\, besides the old issue by allowing them in pathnames and other strings args to syscalls.

But since I have not much to add to my initial complaint to perl5-security-report I rather posted now the patches to fix these issues altogether\, to break the rather silly security interpretation deadlock\, with the new risc that 5.18 will also be affected.

Well\, it is of course your prerogative not to provide an example; however\, I have to say that until you come up with such an example\, I think we're going to continue assuming that 5.16 and later is secure\, and that in particular\, 5.16.x is no less secure than 5.14.x.

One consequence of that is that we are going to be less minded to accept a patch that allows for warns or croaks against such symbols.

-- Gravity is just a theory; teach Intelligent Falling in our schools!   http​://www.theonion.com/content/node/39512

[p5pRT]

From @avar

On Sun\, Mar 3\, 2013 at 9​:01 AM\, Linda Walsh \perlbug\-followup@&#8203;perl\.org wrote​:

So what's the scoop? To enforce this various other binaries on the system do run-time checks or load-time checks for specific versions of perl (as well any perl-using rpm having a reliance on a specific (not a minimum) version of perl. For example SuSE 12.1 was built with perl 5.14.\. When I wanted to upgrade to perl 5.16\, I wasn't allowed to unless I upgraded my system to 12.2 (for 5.16.1) or the unreleased Factory (12.3) for 5.16.2.

[...]

Is the perl ABI really that unstable that venders have to lock the version now or is SuSE being overreactive?

I think everyone in this thread is kind of missing the point of this part of the question and how it really doesn't matter that we're discussing perl for the purposes of a complete answer to it.

It really has nothing to do with perl in particular\, but seemingly Linda's gap in knowledge of how Linux distributions handle major upgrades for *any* software.

It doesn't matter if you have a 100% binary compatible software package Foo version 1\, A Linux distribution like SuSE is still only going to release foo-1.* with the version you installed\, and only upgrade to foo-2.* for their next major release.

That's the whole point of using a Linux distribution at a given release\, you install it within that release version you're supposed to get the *same* major versions of the packages you installed\, but maybe with some critical bug fixes applied on top. If you want more major changes you install the next major release.

As others have pointed out in this thread​: If your needs are different just package perl yourself instead of relying on the system perl.

[p5pRT]

From perl-diddler@tlinx.org

On Thu May 09 10​:11​:40 2013\, avarab@​gmail.com wrote​:

Is the perl ABI really that unstable that venders have to lock the version now or is SuSE being overreactive?

I think everyone in this thread is kind of missing the point of this part of the question and how it really doesn't matter that we're discussing perl for the purposes of a complete answer to it.

It really has nothing to do with perl in particular\, but seemingly Linda's gap in knowledge of how Linux distributions handle major upgrades for *any* software.

It doesn't matter if you have a 100% binary compatible software package Foo version 1\, A Linux distribution like SuSE is still only going to release foo-1.* with the version you installed\, and only upgrade to foo-2.* for their next major release.

That's the whole point of using a Linux distribution at a given release\, you install it within that release version you're supposed to get the *same* major versions of the packages you installed\, but maybe with some critical bug fixes applied on top. If you want more major changes you install the next major release.

---

  I'm not sure if I am confused about what you are saying\, or not. The issue is solely about upgrading between major versions\, but minor versions as well. Suse 12.1​: perl 5.14.2\, suse 12.2​: perl 5.16.0 suse 12.3​: perl 5.16.2\, factory(current)​: 5.16

  While I have little issue that upgrading from 5.14.X to 5.16.X would require a recompile -- it doesn't seem that going between minor releases of 5.16.0->.1->.2->.3 should create large compatibility concerns\, but the vendor ALSO prevents you from minor upgrades as well. Not all packages they release have this issue -- example​: python\, which only has library dirs for "python2.7" and "python3.2".

But upgrade perl from 5.16.0 to 5.16.1 or .2 -- and you start getting failures from products like 'gvim' -- which they bind to specific subreleases -- not just by pathname (I submitted a patch to dynamically load perl\, python and ruby at runtime if they were present -- else\, bring up the editor without the missing libraries being callable from within vim). But even having libperl.so -- runtimes in installed scripts also have been made to ask for minor versions. So vim wouldn't come up due to a perl-extension wanting 5.16.0 instead of 5.16.1. The patch also had to remove specific dependencies on version that would be encoded into extensions at rpmbuild time -- but not be updated by a cpan recompile of all perl modules (because cpan doesn't know about rpm versions).

Perhaps you were trying to say that it's reasonable for vendors not to allow minor updates? Or major updates with no recompile of perl modules? Or did you it was only about going from 5.14->5.16 without recompiling modules?

It's not entirely clear which of those\, if any\, you were referring to. (?) Thanks for the input!

[p5pRT]

From @avar

On Thu\, May 9\, 2013 at 10​:18 PM\, Linda Walsh via RT \perlbug\-followup@&#8203;perl\.org wrote​:

On Thu May 09 10​:11​:40 2013\, avarab@​gmail.com wrote​:

Is the perl ABI really that unstable that venders have to lock the version now or is SuSE being overreactive?

I think everyone in this thread is kind of missing the point of this part of the question and how it really doesn't matter that we're discussing perl for the purposes of a complete answer to it.

It really has nothing to do with perl in particular\, but seemingly Linda's gap in knowledge of how Linux distributions handle major upgrades for *any* software.

It doesn't matter if you have a 100% binary compatible software package Foo version 1\, A Linux distribution like SuSE is still only going to release foo-1.* with the version you installed\, and only upgrade to foo-2.* for their next major release.

That's the whole point of using a Linux distribution at a given release\, you install it within that release version you're supposed to get the *same* major versions of the packages you installed\, but maybe with some critical bug fixes applied on top. If you want more major changes you install the next major release. ----

I'm not sure if I am confused about what you are saying\, or not\.

The issue is solely about upgrading between major versions\, but minor versions as well. Suse 12.1​: perl 5.14.2\, suse 12.2​: perl 5.16.0 suse 12.3​: perl 5.16.2\, factory(current)​: 5.16

While I have little issue that upgrading from 5\.14\.X to 5\.16\.X would

require a recompile -- it doesn't seem that going between minor releases of 5.16.0->.1->.2->.3 should create large compatibility concerns\, but the vendor ALSO prevents you from minor upgrades as well. Not all packages they release have this issue -- example​: python\, which only has library dirs for "python2.7" and "python3.2".

Your initial E-Mail mentions difficulties upgrading from 5.14 to 5.16 because the OS is pinned to 5.14. That's what I was addressing.

But as for them blocking minor release upgrades that seems unreasonable\, perl is fully binary compatible within minor releases\, and the should be able to just require 5.16.*.

But in any case this is a thing to take up with SuSE. They'll know better than we do why they've chosen to package Perl like this.