REPLACE_PERL version mismatch

[Edgar Fuß]

I built a (local) package on 2014Q1, and REPLACE_PERL seems to have put a
#!/usr/pkg/bin/perl5.18.2
shebang in it. I can install that package on a machine with a 2013Q4 perl
(version 5.18.1) because the package dependency is just
perl<5.20.0
perl>=5.18.0
but obviously it won't run.

So either the dependency should be fixed or the shebang changed to a new
perl5.18 link.

[Greg Troxel]

Post by Edgar Fuß
I built a (local) package on 2014Q1, and REPLACE_PERL seems to have put a
#!/usr/pkg/bin/perl5.18.2
shebang in it. I can install that package on a machine with a 2013Q4 perl
(version 5.18.1) because the package dependency is just
perl<5.20.0
perl>=5.18.0
but obviously it won't run.
So either the dependency should be fixed or the shebang changed to a new
perl5.18 link.

It seems best to REPLACE_PERL with just /usr/pkg/bin/perl, rather than
the fully-qualified path, since we don't support parallel installs of
perl.
Otherwise, one could consider changing the perl micro version to be an
ABI change requiring revbumps.

[Thomas Klausner]

Post by Greg Troxel

Post by Edgar Fuß
I built a (local) package on 2014Q1, and REPLACE_PERL seems to have put a
#!/usr/pkg/bin/perl5.18.2
shebang in it. I can install that package on a machine with a 2013Q4 perl
(version 5.18.1) because the package dependency is just
perl<5.20.0
perl>=5.18.0
but obviously it won't run.
So either the dependency should be fixed or the shebang changed to a new
perl5.18 link.

It seems best to REPLACE_PERL with just /usr/pkg/bin/perl, rather than
the fully-qualified path, since we don't support parallel installs of
perl.
Otherwise, one could consider changing the perl micro version to be an
ABI change requiring revbumps.

All the files I have in /usr/pkg/bin have /usr/pkg/bin/perl as
shebang. I don't have a single one that matches "/perl5".

Try finding out how you that happened for you, I don't think it's
typical.
Thomas

[Edgar Fuß]

Post by Thomas Klausner
All the files I have in /usr/pkg/bin have /usr/pkg/bin/perl as
shebang. I don't have a single one that matches "/perl5".

Hm. Looks like REPLACE_PERL puts in /usr/pkg/bin/perl, but during
stage-install, that gets changed to /usr/pkg/bin/perl5.18.2

Post by Thomas Klausner
Try finding out how you that happened for you, I don't think it's
typical.

It looks like a standard Perl module with PERL5_MODULE_TYPE=Module::Build.

[Edgar Fuß]

TK> All the files I have in /usr/pkg/bin have /usr/pkg/bin/perl as
TK> shebang. I don't have a single one that matches "/perl5".
EF> Hm. Looks like REPLACE_PERL puts in /usr/pkg/bin/perl, but during
EF> stage-install, that gets changed to /usr/pkg/bin/perl5.18.2

TK> Try finding out how you that happened for you, I don't think it's
TK> typical.
EF> It looks like a standard Perl module with PERL5_MODULE_TYPE=Module::Build.
Looks like converters/txt2html is also affected. As should be textproc/po4a.

My understanding is that recent versions of Module::Build put a path to the
version-qualified Perl interpreter into the "Build" file, where it seems to
be picked up at later stages.

[Thomas Klausner]

Post by Edgar Fuß
TK> All the files I have in /usr/pkg/bin have /usr/pkg/bin/perl as
TK> shebang. I don't have a single one that matches "/perl5".
EF> Hm. Looks like REPLACE_PERL puts in /usr/pkg/bin/perl, but during
EF> stage-install, that gets changed to /usr/pkg/bin/perl5.18.2
TK> Try finding out how you that happened for you, I don't think it's
TK> typical.
EF> It looks like a standard Perl module with PERL5_MODULE_TYPE=Module::Build.
Looks like converters/txt2html is also affected. As should be textproc/po4a.
My understanding is that recent versions of Module::Build put a path to the
version-qualified Perl interpreter into the "Build" file, where it seems to
be picked up at later stages.

Ok, so why does this happen for you and noone else (yet?)?
Thomas

[Edgar Fuß]

TK> All the files I have in /usr/pkg/bin have /usr/pkg/bin/perl as
TK> shebang. I don't have a single one that matches "/perl5".
EF> Hm. Looks like REPLACE_PERL puts in /usr/pkg/bin/perl, but during
EF> stage-install, that gets changed to /usr/pkg/bin/perl5.18.2

TK> Try finding out how you that happened for you, I don't think it's
TK> typical.
EF> It looks like a standard Perl module with PERL5_MODULE_TYPE=Module::Build.
EF> Looks like converters/txt2html is also affected. As should be textproc/po4a.

EF> My understanding is that recent versions of Module::Build put a path to the
EF> version-qualified Perl interpreter into the "Build" file, where it seems to
EF> be picked up at later stages.

TK>Ok, so why does this happen for you and noone else (yet?)?
Packages both using PERL5_MODULE_TYPE=Module::Build and installing a "binary"
seem to be rare.
What happens if you build converters/txt2html?

[Thomas Klausner]

Post by Edgar Fuß
What happens if you build converters/txt2html?

=> Creating binary package /packages/All/txt2html-2.51nb2.tgz

# txt2html -h
Option h requires an argument
/usr/pkg/bin/txt2html
Usage:
txt2html --help | --manpage

txt2html [ --append_file *filename* ] [ --append_head *filename* ] [
--body_deco *string* ] [ --bold_delimiter *string* ] [ --bullets
*string* ] [ --bullets_ordered *string* ] [ --caps_tag *tag* ] {
--custom_heading_regexp *regexp* } [ --debug ] [ --demoronize ] [
--default_link_dict *filename* ] [ --dict_debug *n* ] [ --doctype
*doctype* ] [ --eight_bit_clean ] [ --escape_HTML_chars ] [
--explicit_headings ] [ --extract ] [ --hrule_min *n* ] [ --indent_width
*n* ] [ --indent_par_break ] { --infile *filename* | --instring *string*
} [ --italic_delimiter *string* ] { --links_dictionaries *filename* } [
--link_only ] [ --lower_case_tags ] [ --mailmode ] [ --make_anchors ] [
--make_tables ] [ --min_caps_length *n* ] [ --outfile *filename* ] [
--par_indent *n* ] [ --preformat_trigger_lines *n* ] [
--endpreformat_trigger_lines *n* ] [ --preformat_start_marker *regexp* ]
[ --preformat_end_marker *regexp* ] [ --preformat_whitespace_min *n* ] [
--prepend_file *filename* ] [ --preserve_indent ] [ --short_line_length
*n* ] [ --style_url *stylesheet_url* ] [ --tab_width *n* ] [
--table_type *type*=0/1 ] [ --title *title* ] [ --titlefirst ] [
--underline_delimiter *string* ] [ --underline_length_tolerance *n* ] [
--underline_offset_tolerance *n* ] [ --unhyphenation ] [
--use_mosaic_header ] [ --use_preformat_marker ] [ --xhtml ] [file ...]


Works.
Thomas

[Edgar Fuß]

Post by Thomas Klausner
=> Creating binary package /packages/All/txt2html-2.51nb2.tgz

Yes, but's what the shebang in txt2html?

[Thomas Klausner]

Post by Edgar Fuß

Post by Thomas Klausner
=> Creating binary package /packages/All/txt2html-2.51nb2.tgz

Yes, but's what the shebang in txt2html?

#!/usr/pkg/bin/perl

Thomas

[Edgar Fuß]

OK, I've tracked this down to Perl's $^X being /usr/pkg/bin/perl5.18.2
(and not simply perl), even if I explicitly do
/usr/pkg/bin/perl -e 'print "$^X\n";'
Does anyone else see this?
I've built lang/perl from pkgsrc-2014Q1 on 6.1/amd64.

[Edgar Fuß]

It turns out that perl readlink(2)s /proc/curproc/exe.
Both /usr/pkg/bin/perl and /usr/pkg/bin/perl5.18.2 are links to the same
inode, so it's probably random which one will turn up in /proc/curproc/exe.

If I ln /usr/pkg/bin/perl /usr/pkg/libexec/perl, running
/usr/pkg/bin/perl -e 'print "$^X\n";'
will output
usr/pkg/libexec/perl
as will both
/usr/pkg/bin/perl5.18.2 -e 'print "$^X\n";'
and
/usr/pkg/libexec/perl -e 'print "$^X\n";'
.

So in order for the bug to happen, you need
1. A perl package using Module::Build
2. A "binary" in the package
3. A certain drectory order (or other random input)

[Edgar Fuß]

Post by Edgar Fuß
will output
usr/pkg/libexec/perl

Sorry, that was, of course, ment to read
/usr/pkg/libexec/perl