Andreas Schwab wrote:

Bjoern Voigt writes:

...

Perl itself is version 5.22.1 (perl-5.22.1-1.1.x86_64). But the packages are still 5.22.0. I which way is that a problem? Perl should still be able to use the modules. Perl 5.22.0 does not find the modules compiled for 5.22.1, because Perl 5.22.0 does not search the 5.22.1 paths.

If you use such a module, you will see errors like this (it's from my logs and an own package perl-File-Scan-ClamAV; I already downgraded, so I am unable to show an other example without much upgrade/downgrade work): 2014-12-23T10:18:05.644476+01:00 mybox spamd[1900]: Can't locate File/Scan/ClamAV.pm in @INC (you may need to install the File::Scan::ClamAV module) (@INC contains: /usr/lib/perl5/vendor_perl/5.20.1/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.20.1 /usr/lib/perl5/site_perl/5.20.1/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.20.1 /usr/lib/perl5/5.20.1/x86_64-linux-thread-multi /usr/lib/perl5/5.20.1 /usr/lib/perl5/site_perl) at /etc/mail/spamassassin/clamav.pm line 17. I not sure, how Tumbleweed build system handles Perl updates. In other rolling release distributions all dependent Perl packages (and packages using Perl) have to be re-compiled after Perl version updates. E.g. in FreeBSD you have such instructions for Perl updates: from /usr/ports/UPDATING (FreeBSD ports collection): 20150513: AFFECTS: users of lang/perl5* AUTHOR: mat@FreeBSD.org The default Perl version has been switched to Perl 5.20. If you are using binary packages to upgrade your system, you do not have anything to do, pkg upgrade will do the right thing. For the other people, assuming you are migrating from 5.18 to 5.20, do: Portupgrade users: portupgrade -o lang/perl5.20 -f lang/perl5.18 portupgrade -f `pkg shlib -R libperl.so.5.18|tail +2` Portmaster users: portmaster -o lang/perl5.20 lang/perl5.18 portmaster -f `pkg shlib -R libperl.so.5.18|tail +2` NOTE: Perl has been removed from base more than ten years ago, so it was way past time for the /usr/bin/perl symlink to be removed from the port. If for some strange reason, you still need it, you will have to create it manually. IMPORTANT: In case you have not updated your system in a while, and specifically, followed the 20141126 instructions regarding the new Perl layout, you should follow those more extensive instructions rather than the conservative presented here. I wonder, why nobody else seems to have Perl problems with the latest Tumbleweed snapshot 20160222? Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi, On 25 Feb 10:39, Dominique Leuenberger / DimStar wrote:

The rpm correctly requires perl(:MODULE_COMPAT_5.22.0) (as it was built against 5.22.0)

perl 5.22.1 provides this symbol, thus implying for the build service / checker scripts that there is nothing wrong here and this packaged does not need a rebuild. So the question would mainly be: why does perl 5.22.1 provide this symbol? Is this symbol not usable for what it is being used for? And why of why does a minor version update of perl really need a rebuild of all perl modules with such a strict path setup.

I'd recommend a bug report against perl to have those questions evaluated.

perl -V shows that the following is in the search path: /usr/lib/perl5/vendor_perl/5.22.0/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.22.0 so it does have 5.22.0 compat. Regards, ismail

On Thu, 2016-02-25 at 10:10 +0100, Bjoern Voigt wrote:

Andreas Schwab wrote:

...

Bjoern Voigt writes:

...

Perl itself is version 5.22.1 (perl-5.22.1-1.1.x86_64). But the packages are still 5.22.0.

I which way is that a problem?  Perl should still be able to use the modules.

Perl 5.22.0 does not find the modules compiled for 5.22.1, because Perl 5.22.0 does not search the 5.22.1 paths.

But you were going the other way: perl 5.22.1 should find the 5.22.0 moduldes (it's backwards compatible. not forward compatible)

    2014-12-23T10:18:05.644476+01:00 mybox spamd[1900]: Can't locate File/Scan/ClamAV.pm in @INC (you may need to install the File::Scan::ClamAV module) (@INC contains: /usr/lib/perl5/vendor_perl/5.20.1/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.20.1 /usr/lib/perl5/site_perl/5.20.1/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.20.1 /usr/lib/perl5/5.20.1/x86_64-linux- thread-multi /usr/lib/perl5/5.20.1 /usr/lib/perl5/site_perl) at /etc/mail/spamassassin/clamav.pm line 17.

Where are perl 5.20 paths coming from there! We were discussing 5.22.0 to 5.22.1 upgrade issues... But yes, in December 2014 we might have switched from 5.20 a notch up :) (check the date/timestamp of that log extract) Probably there was no problem to start with? Other than you seeing directories you expected to disappear? Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andreas Schwab wrote:

Of course, it doesn't. It only works the other way round. May be it should work. But this did not work for me. So I have to upgrade perl/perl-base again to 5.22.1 to be able to present test cases again.

Other question: Why are depended Perl modules not recompiled anyway? (I understood openSUSE build system so, that dependent packages are re-compiled and published automatically. Having several 5.22.0, 5.22.1, ... directories is confusing for users too.) Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Bjoern Voigt writes:

Perl 5.22.0 does not find the modules compiled for 5.22.1, because Perl 5.22.0 does not search the 5.22.1 paths.

If you use such a module, you will see errors like this (it's from my logs and an own package perl-File-Scan-ClamAV; I already downgraded, so I am unable to show an other example without much upgrade/downgrade work):

2014-12-23T10:18:05.644476+01:00 mybox spamd[1900]: Can't locate File/Scan/ClamAV.pm in @INC (you may need to install the File::Scan::ClamAV module) (@INC contains: /usr/lib/perl5/vendor_perl/5.20.1/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.20.1 /usr/lib/perl5/site_perl/5.20.1/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.20.1 /usr/lib/perl5/5.20.1/x86_64-linux-thread-multi /usr/lib/perl5/5.20.1 /usr/lib/perl5/site_perl) at /etc/mail/spamassassin/clamav.pm line 17.

It seems you are having modules that search for a 5.20.1 module path or you somehow manage to modify @INC in other ways. This has nothing to do whatsoever with the upgrade of 5.22.0 to 5.22.1.

I not sure, how Tumbleweed build system handles Perl updates. In other rolling release distributions all dependent Perl packages (and packages using Perl) have to be re-compiled after Perl version updates.

No, only major releases are binary incompatible. A minor update liek the one from 5.22.0 to 5.22.1 is binary compatible as long as the configuration is not changed. And seeing that 5.22.1 does look for modules from 3.22.0, is a good indication that these two versions are in fact binary compatible: Built under linux Compiled at Feb 17 2016 09:49:09 @INC: /usr/lib/perl5/site_perl/5.22.1/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.22.1 /usr/lib/perl5/vendor_perl/5.22.1/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.22.1 /usr/lib/perl5/5.22.1/x86_64-linux-thread-multi /usr/lib/perl5/5.22.1 /usr/lib/perl5/site_perl/5.22.0/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.22.0 /usr/lib/perl5/vendor_perl/5.22.0/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.22.0 /usr/lib/perl5/site_perl . I'd rather put everything under 5.22 and drop the sub-release entirely, but the way things are configured is correct.

E.g. in FreeBSD you have such instructions for Perl updates:

That's for a major version upgrade.

I wonder, why nobody else seems to have Perl problems with the latest Tumbleweed snapshot 20160222?

Because they don't have old Perl modules installed that are still assuming 5.20.1? How did you end up with @INC containing 5.20.1 anyway? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Bjoern Voigt writes:

But is this really your output of "perl -V" from perl-5.22.1-1.1.x86_64?

Yes.

The following two lines are missing in my "perl -V" output. Why?

/usr/lib/perl5/site_perl/5.22.0/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.22.0

Most likely you didn't have anything installed there while you were using 5.22.0, so it doesn't need to be added to @INC. I have a few modules installed from CPAN that weren't updated after the update to 5.22.1, so it's needed on my system. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org