[opensuse-packaging] packaging Perl modules with no hard Perl version dependency
Adam Spiers (aspiers@suse.com) wrote to opensuse-factory:
Hi,
Back in 2011 I became maintainer of GNU Stow, and since then have built an package which lives in the OBS system:packagemanager project:
https://build.opensuse.org/package/show/system:packagemanager/stow
I would like it to be in Factory too, so I have submitted a request:
During the review for this SR, I noticed this rpmlint warning: stow.noarch: W: no-dependency-on perl-base 5.18.1 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. 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. 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*. 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? Thanks! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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.)
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?
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. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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
Adam Spiers (aspiers@suse.com) wrote:
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 forgot to say - even with %perl_requires, rpmlint still complains: stow.noarch: W: no-dependency-on perl-base 5.18.1 What's the idea behind this check? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Sep 12, 2013 at 02:22:57PM +0100, Adam Spiers wrote:
Is the idea that perl-base-5.18.x for x >= 2 will still provide this symbol?
Yes, the perl-5.18.1 in Factory already provides both perl(:MODULE_COMPAT_5.18.0) and perl(:MODULE_COMPAT_5.18.1), as @INC contains both directories. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, Am Donnerstag, 12. September 2013 schrieb Michael Schroeder:
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.)
This means we'll have a quite big @INC in perl 5.18.42 ;-) Can we introduce a directory that only contains the major perl version, maybe /usr/lib/perl5/vendor_perl/5.18.X or just /usr/lib/perl5/vendor_perl/5.18 instead of making @INC bigger?
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?
You never know - I even had a case where a stable operator (~~) was marked as experimental again in a newer perl version... That said: the current packaging with %perl_requires etc. does not prevent those issues - the only advantage of versioned directories is that you have to install a new build of the now-broken module ;-) Regards, Christian Boltz -- Sorry, aber der Anforderungskatalog liest sich ungefähr so, als ob Du einen familienfreundlichen Ferrari-Kombi der weniger als drei Liter auf 100 km benötigt möchtest. [Manfred Tremmel in suse-laptop] -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, Sep 13, 2013 at 02:06:26AM +0200, Christian Boltz wrote:
This means we'll have a quite big @INC in perl 5.18.42 ;-)
My hope is that by then we'll use perl 5.22.3
Can we introduce a directory that only contains the major perl version, maybe /usr/lib/perl5/vendor_perl/5.18.X or just /usr/lib/perl5/vendor_perl/5.18 instead of making @INC bigger?
The perl people make sure that newer perls work with older perl modules, but perl modules compiled with new perl versions don't need to work with old perl versions (because of new symbols). Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Michael Schroeder (mls@suse.de) wrote:
On Fri, Sep 13, 2013 at 02:06:26AM +0200, Christian Boltz wrote:
This means we'll have a quite big @INC in perl 5.18.42 ;-)
My hope is that by then we'll use perl 5.22.3
Even by 5.18.5 this gets quite ugly :-/
Can we introduce a directory that only contains the major perl version, maybe /usr/lib/perl5/vendor_perl/5.18.X or just /usr/lib/perl5/vendor_perl/5.18 instead of making @INC bigger?
The perl people make sure that newer perls work with older perl modules, but perl modules compiled with new perl versions don't need to work with old perl versions (because of new symbols).
That's only relevant to Perl modules which require compilation, isn't it? There are plenty of modules which are pure Perl and no C (the majority, I think). -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thursday 2013-09-12 14:13, Michael Schroeder wrote:
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?
Yet we have a bunch packages that contain {#!/usr/bin/perl scripts} and {nothing in /usr/lib/perl}, and which do not have a version number dependency either and there is no apparent issue of those. SuSEfirewall2-3.6.302-1.1.1.noarch build-20130517-1.1.noarch ghostscript-fonts-std-9.06-2.1.1.noarch latex2html-2008-20.1.1.noarch psutils-p17-1018.1.1.x86_64 quilt-0.60-5.1.1.noarch xdg-utils-20120916-2.1.1.noarch for example. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (4)
-
Adam Spiers -
Christian Boltz -
Jan Engelhardt -
Michael Schroeder