Michael Schroeder (mls@suse.de) wrote:
On Thu, Sep 12, 2013 at 12:58:43PM +0100, Adam Spiers wrote:
It seems that currently my .spec results in the package containing files such as:
/usr/lib/perl5/vendor_perl/5.18.1/Stow.pm
which will only be found by the default @INC of a perl-5.18.1 package.
(It will also be found by perl-5.18.2 and so on.)
Ah, right - that should be good enough then.
However, I know for a fact that my non-binary modules will work with *any* Perl >= 5.6.1, and so would prefer to install them to a non-versioned directory, e.g.
$ perl -V:vendorlib_stem vendorlib_stem='/usr/lib/perl5/vendor_perl';
However this is not on the default @INC.
Well, completely unversioned is a bit frowned upon. There are incompatible changes between the major perl versions, and how will you know that perl-5.20 does not break your module?
That seems extremely unlikely (since it didn't break since 5.6.1 days), but OK, point accepted.
In contrast, sitelib_stem does seem to be, although my understanding is that "vendor" packages such as those from OBS should install to vendor* paths rather than site*.
sitelib_stem is there because some people really want to have versionless modules locally.
Is there a good reason for vendorlib_stem not being on @INC, and if so, is it OK for me to install to sitelib_stem instead?
I consider it bad style, IMHO sitelib is a place where local admins can install stuff, e.g. by directly calling the cpan tool.
OK, I'll stick with vendorlib then. But then what's the correct way express this dependency? If I put %perl_requires in the .spec file, then for older openSUSE versions such as 12.1 it results in something like manual: perl = 5.14.2 which would incorrectly break with 5.14.3, and for Factory it results in manual: perl(:MODULE_COMPAT_5.18.1) Is the idea that perl-base-5.18.x for x >= 2 will still provide this symbol? I read http://en.opensuse.org/openSUSE:Packaging_Conventions_RPM_Macros#.25perl_ver... http://en.opensuse.org/openSUSE:Packaging_Perl#.25perl_version but these packages seem out of date, incomplete, and to some extent duplicate each other. At risk of stating the totally obvious, it would seem sensible to only document them on one of the pages, and have the other link to it, to avoid them getting out of sync. DRY is just as important in documentation as in code! Thanks a lot for the useful reply! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org