Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 987009
Please note that this Bug is private and may not be accessible as it contains confidential Red Hat customer information.
Description of problem: Following executable scripts contain shebang with /usr/bin/env <lang>. There might be an issue that the script is executed with unwanted version of <lang> if that language is provided by enabled collection [1]. Please change the shebang to absolute path if that is not designed behaviour. Affected scripts: /usr/sbin/ns-newpwpolicy.pl: #!/usr/bin/env perl /usr/sbin/ns-inactivate.pl: #!/usr/bin/env perl /usr/sbin/db2bak.pl: #!/usr/bin/env perl /usr/sbin/syntax-validate.pl: #!/usr/bin/env perl /usr/sbin/schema-reload.pl: #!/usr/bin/env perl /usr/sbin/ns-activate.pl: #!/usr/bin/env perl /usr/sbin/db2ldif.pl: #!/usr/bin/env perl /usr/sbin/db2index.pl: #!/usr/bin/env perl /usr/sbin/migrate-ds.pl: #!/usr/bin/env perl /usr/sbin/bak2db.pl: #!/usr/bin/env perl /usr/sbin/remove-ds.pl: #!/usr/bin/env perl /usr/sbin/ns-accountstatus.pl: #!/usr/bin/env perl /usr/sbin/cleanallruv.pl: #!/usr/bin/env perl /usr/sbin/verify-db.pl: #!/usr/bin/env perl /usr/sbin/fixup-memberof.pl: #!/usr/bin/env perl /usr/sbin/ldif2db.pl: #!/usr/bin/env perl /usr/sbin/setup-ds.pl: #!/usr/bin/env perl /usr/sbin/usn-tombstone-cleanup.pl: #!/usr/bin/env perl /usr/sbin/fixup-linkedattrs.pl: #!/usr/bin/env perl /usr/bin/logconv.pl: #!/usr/bin/env perl /usr/bin/repl-monitor.pl: #!/usr/bin/env perl /usr/bin/dbgen.pl: #!/usr/bin/env perl /usr/bin/cl-dump.pl: #!/usr/bin/env perl /usr/bin/ds-logpipe.py: #!/usr/bin/env python Version-Release number of selected component (if applicable): 389-ds-base-1.3.1.2-1.el7.x86_64
Next, "--with-perldir=/usr/bin" needs to be added to spec files for Fedora and RHEL...
Please use the same version of autoconf/automake that was used the last time - all of the autotool generated files makes the diff huge.
This logic is faulty {{{ +if test "$with_perldir" = yes ; then + if test -n "$with_perldir" ; then + AC_MSG_RESULT([$with_perldir]) + else + AC_MSG_ERROR([You must specify --with-perldir=/full/path/to/perl]) + fi }}} If test "$with_perldir" = yes is true, then test -n "$with_perldir" will always be true.
Looking at the file, I see the systemd stuff uses the same faulty logic :-(
Replying to [comment:5 rmeggins]:
I did. I'm on f19, and this is what i used the last time I made an update to configure/Makefile. Is this incorrect now?
This logic is faulty {{{ +if test "$with_perldir" = yes ; then + if test -n "$with_perldir" ; then + AC_MSG_RESULT([$with_perldir]) + else + AC_MSG_ERROR([You must specify --with-perldir=/full/path/to/perl]) + fi }}} If test "$with_perldir" = yes is true, then test -n "$with_perldir" will always be true. Looking at the file, I see the systemd stuff uses the same faulty logic :-(
I'll clean all of this up.
Replying to [comment:6 mreynolds]:
Replying to [comment:5 rmeggins]: Please use the same version of autoconf/automake that was used the last time - all of the autotool generated files makes the diff huge. I did. I'm on f19, and this is what i used the last time I made an update to configure/Makefile. Is this incorrect now?
I see - Noriko made this commit: commit e0c78d5 Author: Noriko Hosoi nhosoi@redhat.com Date: Thu Oct 3 14:21:55 2013 -0700
she must have used F18. Let's talk about it on the devel list - if everyone is comfortable with switching to F19, let's do that. We need to reduce this churn.
This logic is faulty {{{ +if test "$with_perldir" = yes ; then + if test -n "$with_perldir" ; then + AC_MSG_RESULT([$with_perldir]) + else + AC_MSG_ERROR([You must specify --with-perldir=/full/path/to/perl]) + fi }}} If test "$with_perldir" = yes is true, then test -n "$with_perldir" will always be true. Looking at the file, I see the systemd stuff uses the same faulty logic :-( I'll clean all of this up.
Initial diff before running autogen.sh configure.diff
While waiting for a response on which autogen.sh to use, I've attached a new diff with just the changes in configure.ac
Although it seems like a good idea to check for the existence of $with_perldir/perl and $with_systemdsystemunitdir and $with_systemdsystemconfdir, this can cause problems if you build on a system where they don't exist. If they are explicit build time dependencies (e.g. you can't build if test -d /usr/include/nspr4 fails), then it is appropriate to test for the existence of include/lib directories. We've run into problems like this in the past, which is why we don't generally check, at build time, for files/dirs that may only be available at run time. Perhaps just a warning in that case.
revision 0001-Ticket-47436-389-ds-base-shebang-with-usr-bin-env.patch
Replying to [comment:9 rmeggins]:
Ahhh, good to know. Ok, new full patch is attached.
git merge ticket47436 Updating 1e035d1..7da55a2 Fast-forward Makefile.in | 4950 ++++++++++++++++++++++++++++++---------------------------- aclocal.m4 | 334 +++-- compile | 9 +- config.guess | 182 ++- config.sub | 88 +- configure | 92 +- configure.ac | 24 +- depcomp | 454 ++++--- missing | 405 ++--- 9 files changed, 3426 insertions(+), 3112 deletions(-)
git push origin master Counting objects: 21, done. Delta compression using up to 4 threads. Compressing objects: 100% (10/10), done. Writing objects: 100% (11/11), 58.08 KiB, done. Total 11 (delta 6), reused 5 (delta 1) To ssh://git.fedorahosted.org/git/389/ds.git 1e035d1..7da55a2 master -> master
commit 7da55a2 Author: Mark Reynolds mreynolds@redhat.com Date: Thu Oct 10 12:01:56 2013 -0400
Metadata Update from @rmeggins: - Issue assigned to mreynolds - Issue set to the milestone: 1.3.3 - 10/13 (October)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/773
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Log in to comment on this ticket.