Bug 844810

Summary: The /usr/sbin/osipsconsole script requires programs which are not listed in the Requires section of the package
Product: [Fedora] Fedora EPEL Reporter: John Conroy <jconroy>
Component: opensipsAssignee: Peter Lemenkov <lemenkov>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: el5CC: ivaxer, lemenkov
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-04-06 10:35:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description John Conroy 2012-07-31 21:46:53 UTC
Description of problem:
The /usr/sbin/osipsconsole script in the main opensips RPM requires programs which are not listed in the Requires section of the package and therefore do not get installed along with the script.

Version-Release number of selected component (if applicable):
opensips-1.7.2-2.el5

How reproducible:
Always

Steps to Reproduce:
1.  Install opensips main package
2.  Run /usr/sbin/osipsconsole
3.  Install DB specific sub-packages (-dbberkeley or -mysql)
4.  Run /usr/sbin/osipsconsole
  
Actual results:
which: no md5 in (/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/root/bin)
which: no mysql in (/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/root/bin)
Error: 'mysql' tool not found: set MYSQL variable to correct tool pathwhich: no db_dump in (/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/root/bin)
which: no db4.4_dump in (/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/root/bin)
which: no db4.5_dump in (/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/root/bin)
which: no db4.6_dump in (/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/root/bin)
which: no db_load in (/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/root/bin)
which: no db4.4_load in (/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/root/bin)
which: no db4.5_load in (/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/root/bin)
which: no db4.6_load in (/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/root/bin)
Control engine FIFO loaded
OpenSIPS$:quit
Thank you for flying Opensips!!

Expected results:
Install proper requirements (based on subpackage installed? ie: -dbberkely or -mysql)
No errors running the "which" commands (redirect STDERR to /dev/null)

Additional info:
The script does not redirect STDERR so the failures are written to the console:

=================from script=================================
#berkeley db utility program that writes out db to plain text
#small hack to autodetect the db dump command, debian prefix the version..

system("which db_dump > /dev/null");
if ( $? == 0 ) {
        $DUMP_CMD = "db_dump";
}

system("which db4.4_dump > /dev/null");
if ( $? == 0 ) {
        $DUMP_CMD = "db4.4_dump";
}

system("which db4.5_dump > /dev/null");
if ( $? == 0 ) {
        $DUMP_CMD = "db4.5_dump";
}

system("which db4.6_dump > /dev/null");
if ( $? == 0 ) {
        $DUMP_CMD = "db4.6_dump";
}

#berkeley db utility program that imports data from plain text file
#small hack to autodetect the db load command, debian prefix the version..

system("which db_load > /dev/null");
if ( $? == 0 ) {
        $LOAD_CMD = "db_load";
}

system("which db4.4_load > /dev/null");
if ( $? == 0 ) {
        $LOAD_CMD = "db4.4_load";
}

system("which db4.5_load > /dev/null");
if ( $? == 0 ) {
        $LOAD_CMD = "db4.5_load";
}

system("which db4.6_load > /dev/null");
if ( $? == 0 ) {
        $LOAD_CMD = "db4.6_load";
}

===============also=======================

               if ( -x "/usr/bin/which" ) {
                        $TOOLPATH = `which @_`;
                        chomp($TOOLPATH);
                        #if ( $TOOLPATH ) {
                        #       return $TOOLPATH;
                        #}
                        return;
                }

Comment 1 Fedora End Of Life 2017-04-06 10:35:05 UTC
Fedora EPEL 5 changed to end-of-life (EOL) status on 2017-03-31. Fedora EPEL 5
is no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora
or Fedora EPEL, please feel free to reopen this bug against that version. If
you are unable to reopen this bug, please file a new report against the current
release. If you experience problems, please add a comment to this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.