Re: Perl Symlinks question
Hi,
On Tue Jan 10 09:57:32 UTC 2012, Erik Tulsson wrote:
On Tue, Jan 10, 2012 at 12:46:51AM +0100, Oliver Heesakkers wrote:
Op ma 09 jan 2012 22:49:33 schreef Ruslan Mahmatkhanov:
Hi.
There is PR: http://bugs.freebsd.org/163687
It tries to fix port building when user built it's perl installation
with USE_PERL option (creating symlinks in /usr/bin) set to off (not the
default). Patch in PR just replaces static shebang with ${PERL} variable
from Mk/bsd.perl.mk. But it doesn't actually fix the build, because
consequent call of aclocal-1.11 will fail since it's shebang set to
'/usr/bin/perl' too.
The question is how to properly handle this PR:
1. Fix devel/automake too (by replacing /usr/bin/perl with ${PERL})
2. Create symlinks unconditionally in perl port and drop USE_PERL option
3. Close PR as invalid since the build fails because of user
intervention (changing the value of default option)
4. Teach upstream (and maybe maintainers) to use /usr/bin/env as they should
do:
http://perldoc.perl.org/perlintro.html#Running-Perl-programs
That may be the modern way of doing it, but older versions of the Perl
documentation used to recommend using /usr/bin/perl, so there are most
likely a ton of perl scripts out there (only a small fraction of which
appears in the FreeBSD ports tree) which use that convention.
It is also worth noting that even the current version of the Perl
documentation refers to /usr/bin/perl in numerous places and recommends
that it exists as a symlink to the perl binary.
As the original reporter, I'd like to keep the option to turn use_perl off.
For two reasons:
1) Those scripts you mention above will never be identified (and fixed) if you
keep the compatibility symlink. Some don't care, some do, which is why the
option (and default setting) are good.
2) When you use a ezjail-like setup with a template jail and read-only nullfs
mounts, it means that all the jails on that template SHALL have the same
perl version, because it links to exact perl binary version, not just
/usr/local/bin/perl. This has bit me before and I decided to get rid of
the symlink in the template jail, rather then creating another template
just for different perl versions.
-- Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Perl symlinks question
On Tue, Jan 10, 2012 at 12:46:51AM +0100, Oliver Heesakkers wrote:
Op ma 09 jan 2012 22:49:33 schreef Ruslan Mahmatkhanov:
Hi.
There is PR: http://bugs.freebsd.org/163687
It tries to fix port building when user built it's perl installation
with USE_PERL option (creating symlinks in /usr/bin) set to off (not the
default). Patch in PR just replaces static shebang with ${PERL} variable
from Mk/bsd.perl.mk. But it doesn't actually fix the build, because
consequent call of aclocal-1.11 will fail since it's shebang set to
'/usr/bin/perl' too.
The question is how to properly handle this PR:
1. Fix devel/automake too (by replacing /usr/bin/perl with ${PERL})
2. Create symlinks unconditionally in perl port and drop USE_PERL option
3. Close PR as invalid since the build fails because of user
intervention (changing the value of default option)
4. Teach upstream (and maybe maintainers) to use /usr/bin/env as they should
do:
http://perldoc.perl.org/perlintro.html#Running-Perl-programs
That may be the modern way of doing it, but older versions of the Perl
documentation used to recommend using /usr/bin/perl, so there are most
likely a ton of perl scripts out there (only a small fraction of which
appears in the FreeBSD ports tree) which use that convention.
It is also worth noting that even the current version of the Perl
documentation refers to /usr/bin/perl in numerous places and recommends
that it exists as a symlink to the perl binary.
--
Insert your favourite quote here.
Erik Trulsson
ertr1...@student.uu.se
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Perl symlinks question
Ruslan Mahmatkhanov cvs-...@yandex.ru writes:
Ruslan Mahmatkhanovcvs-...@yandex.ru writes:
There is PR: http://bugs.freebsd.org/163687
It tries to fix port building when user built it's perl installation
with USE_PERL option (creating symlinks in /usr/bin) set to off (not
the default). Patch in PR just replaces static shebang with ${PERL}
variable from Mk/bsd.perl.mk. But it doesn't actually fix the build,
because consequent call of aclocal-1.11 will fail since it's shebang
set to '/usr/bin/perl' too.
[...]
Can you shed more light on the aclocal issue? Does the submitter know?
nss_ldap installs fine after applying ports/163687.
$ ls -1d /usr/local/share/aclocal*
/usr/local/share/aclocal/
/usr/local/share/aclocal-1.11/
/usr/local/share/aclocal-1.4/
$ fgrep -r /usr/bin/perl /usr/local/share/aclocal*
Exit 1
Sure.
=== Configuring for nss_ldap-1.265_7
env: /usr/local/bin/aclocal-1.11: No such file or directory
*** Error code 127
[rm@smeshariki3 ~/learn] head -3 `which aclocal-1.11`
#!/usr/bin/perl -w
# -*- perl -*-
# Generated from aclocal.in; do not edit by hand.
This line tells enough. aclocal used @PERL@ binary detected during
devel/automake installation. Have you tried to reinstall dependent
ports after turning off USE_PERL option?
Submitter doesn't seems know about (or didn't faced this).
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Perl symlinks question
Hi.
There is PR: http://bugs.freebsd.org/163687
It tries to fix port building when user built it's perl installation
with USE_PERL option (creating symlinks in /usr/bin) set to off (not the
default). Patch in PR just replaces static shebang with ${PERL} variable
from Mk/bsd.perl.mk. But it doesn't actually fix the build, because
consequent call of aclocal-1.11 will fail since it's shebang set to
'/usr/bin/perl' too.
The question is how to properly handle this PR:
1. Fix devel/automake too (by replacing /usr/bin/perl with ${PERL})
2. Create symlinks unconditionally in perl port and drop USE_PERL option
3. Close PR as invalid since the build fails because of user
intervention (changing the value of default option)
Thanks.
As for me, i believe second option is more preferable, but i don't know
if there something behind this.
PS. I think patch attached (for bsd.perl.mk) should be considered since
we no more have perl in base. And i'd also exclude perl-5.6.* from
CONFLICTS in lang/perl*, because it's something so ancient and doubtful
to face with.
--
Regards,
Ruslan
Tinderboxing kills... the drives.
--- bsd.perl.mk.orig2011-08-15 10:50:00.0 +0400
+++ bsd.perl.mk 2012-01-09 22:43:00.0 +0400
@@ -11,10 +11,8 @@
# Please send all suggested changes to the maintainer instead of committing
# them to CVS yourself.
#
-# PERL5- Set to full path of perl5, either in the
system or
-#installed from a port.
-# PERL - Set to full path of perl5, either in the system or
-#installed from a port, but without the
version number.
+# PERL5- Set to full path of perl5
+# PERL - Set to full path of perl5, but without the version
number.
#Use this if you need to replace #! lines in
scripts.
# PERL_VERSION - Full version of perl5 (see below for current value).
# PERL_LEVEL - Perl version as an integer of the form MNNNPP, where
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Perl symlinks question
Adding perl and skv@
On 9 January 2012 18:49, Ruslan Mahmatkhanov cvs-...@yandex.ru wrote:
Hi.
There is PR: http://bugs.freebsd.org/163687
It tries to fix port building when user built it's perl installation with
USE_PERL option (creating symlinks in /usr/bin) set to off (not the
default). Patch in PR just replaces static shebang with ${PERL} variable
from Mk/bsd.perl.mk. But it doesn't actually fix the build, because
consequent call of aclocal-1.11 will fail since it's shebang set to
'/usr/bin/perl' too.
The question is how to properly handle this PR:
1. Fix devel/automake too (by replacing /usr/bin/perl with ${PERL})
2. Create symlinks unconditionally in perl port and drop USE_PERL option
3. Close PR as invalid since the build fails because of user
intervention (changing the value of default option)
Thanks.
As for me, i believe second option is more preferable, but i don't know if
there something behind this.
PS. I think patch attached (for bsd.perl.mk) should be considered since we
no more have perl in base. And i'd also exclude perl-5.6.* from CONFLICTS in
lang/perl*, because it's something so ancient and doubtful to face with.
I don't see any point in the symlink being optional either -- I vote for 2.
Chris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Perl symlinks question
2012/1/9 Chris Rees cr...@freebsd.org:
1. Fix devel/automake too (by replacing /usr/bin/perl with ${PERL})
2. Create symlinks unconditionally in perl port and drop USE_PERL option
/usr/bin is in LOCALBASE which may be read only.
--
Eitan Adler
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Perl symlinks question
Eitan Adler wrote on 09.01.2012 23:32:
2012/1/9 Chris Reescr...@freebsd.org:
1. Fix devel/automake too (by replacing /usr/bin/perl with ${PERL})
2. Create symlinks unconditionally in perl port and drop USE_PERL option
/usr/bin is in LOCALBASE which may be read only.
Ok, but if so most part of ports tree will not build on such systems,
because automake tools (aclocal in particular) calling /usr/bin/perl.
--
Regards,
Ruslan
Tinderboxing kills... the drives.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Perl symlinks question
On Mon, Jan 9, 2012 at 2:36 PM, Ruslan Mahmatkhanov cvs-...@yandex.ru wrote:
Eitan Adler wrote on 09.01.2012 23:32:
2012/1/9 Chris Reescr...@freebsd.org:
1. Fix devel/automake too (by replacing /usr/bin/perl with ${PERL})
2. Create symlinks unconditionally in perl port and drop USE_PERL option
/usr/bin is in LOCALBASE which may be read only.
Ok, but if so most part of ports tree will not build on such systems,
because automake tools (aclocal in particular) calling /usr/bin/perl.
The option should remain on by default due to the majority use case,
but elimination the option is a bad idea. Users should not have to
hack ports to use a readonly LOCALBASE.
--
Eitan Adler
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Perl symlinks question
On 1/9/2012 8:42 PM, Eitan Adler wrote:
On Mon, Jan 9, 2012 at 2:36 PM, Ruslan Mahmatkhanovcvs-...@yandex.ru wrote:
Eitan Adler wrote on 09.01.2012 23:32:
2012/1/9 Chris Reescr...@freebsd.org:
1. Fix devel/automake too (by replacing /usr/bin/perl with ${PERL})
2. Create symlinks unconditionally in perl port and drop USE_PERL option
/usr/bin is in LOCALBASE which may be read only.
Ok, but if so most part of ports tree will not build on such systems,
because automake tools (aclocal in particular) calling /usr/bin/perl.
The option should remain on by default due to the majority use case,
but elimination the option is a bad idea. Users should not have to
hack ports to use a readonly LOCALBASE.
Last time I installed perl with /usr/bin readonly (ezjail) it failed
silently to create the symlink so there is really no reason to switch
this option off.
That's why, I would also go for option 2/
If you have a readonly /usr/bin, it is the job of your administrator
(that'd be you!) to create the symlink.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Perl symlinks question
Ruslan Mahmatkhanov cvs-...@yandex.ru writes:
There is PR: http://bugs.freebsd.org/163687
It tries to fix port building when user built it's perl installation
with USE_PERL option (creating symlinks in /usr/bin) set to off (not
the default). Patch in PR just replaces static shebang with ${PERL}
variable from Mk/bsd.perl.mk. But it doesn't actually fix the build,
because consequent call of aclocal-1.11 will fail since it's shebang
set to '/usr/bin/perl' too.
[...]
Can you shed more light on the aclocal issue? Does the submitter know?
nss_ldap installs fine after applying ports/163687.
$ ls -1d /usr/local/share/aclocal*
/usr/local/share/aclocal/
/usr/local/share/aclocal-1.11/
/usr/local/share/aclocal-1.4/
$ fgrep -r /usr/bin/perl /usr/local/share/aclocal*
Exit 1
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Perl symlinks question
Op ma 09 jan 2012 22:49:33 schreef Ruslan Mahmatkhanov:
Hi.
There is PR: http://bugs.freebsd.org/163687
It tries to fix port building when user built it's perl installation
with USE_PERL option (creating symlinks in /usr/bin) set to off (not the
default). Patch in PR just replaces static shebang with ${PERL} variable
from Mk/bsd.perl.mk. But it doesn't actually fix the build, because
consequent call of aclocal-1.11 will fail since it's shebang set to
'/usr/bin/perl' too.
The question is how to properly handle this PR:
1. Fix devel/automake too (by replacing /usr/bin/perl with ${PERL})
2. Create symlinks unconditionally in perl port and drop USE_PERL option
3. Close PR as invalid since the build fails because of user
intervention (changing the value of default option)
4. Teach upstream (and maybe maintainers) to use /usr/bin/env as they should
do:
http://perldoc.perl.org/perlintro.html#Running-Perl-programs
(this goes for multimedia/ffmpeg or rather texipod.pl included in that build,
too)
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Perl symlinks question
Jan Beich wrote on 10.01.2012 03:06:
Ruslan Mahmatkhanovcvs-...@yandex.ru writes:
There is PR: http://bugs.freebsd.org/163687
It tries to fix port building when user built it's perl installation
with USE_PERL option (creating symlinks in /usr/bin) set to off (not
the default). Patch in PR just replaces static shebang with ${PERL}
variable from Mk/bsd.perl.mk. But it doesn't actually fix the build,
because consequent call of aclocal-1.11 will fail since it's shebang
set to '/usr/bin/perl' too.
[...]
Can you shed more light on the aclocal issue? Does the submitter know?
nss_ldap installs fine after applying ports/163687.
$ ls -1d /usr/local/share/aclocal*
/usr/local/share/aclocal/
/usr/local/share/aclocal-1.11/
/usr/local/share/aclocal-1.4/
$ fgrep -r /usr/bin/perl /usr/local/share/aclocal*
Exit 1
Sure.
=== Configuring for nss_ldap-1.265_7
env: /usr/local/bin/aclocal-1.11: No such file or directory
*** Error code 127
[rm@smeshariki3 ~/learn] head -3 `which aclocal-1.11`
#!/usr/bin/perl -w
# -*- perl -*-
# Generated from aclocal.in; do not edit by hand.
Submitter doesn't seems know about (or didn't faced this).
--
Regards,
Ruslan
Tinderboxing kills... the drives.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
