Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 24037 - Poor coding practices result in broken software
Poor coding practices result in broken software
Product: Red Hat High Availability Server
Classification: Retired
Component: piranha (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Phil Copeland
Phil Copeland
Depends On:
  Show dependency treegraph
Reported: 2001-01-15 12:26 EST by Paul Lussier
Modified: 2007-04-18 12:30 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-01-15 12:49:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Paul Lussier 2001-01-15 12:26:31 EST
Various components of the piranha package have the path to the ipvsadm
command *hardcoded* into the lvsconfig.c and nanny.c files as

Hard coding paths in the source is a very poor coding practice, and results
in broken configurations when the target is not located in the specified

A better alternative would be to make this a configuration option at least
in the the make file so the person installing the software from source can
specify where things really exist on their systems.

The ultimately and most desirable thing would be to use the GNU
Autoconf/Automake tools so someone installing from source can easily
specify on the command line where things exist.  For example, one should be
able to do something like:

	./configure --prefix=/usr/local

so they could install the pirahna package down the /usr/local hierarchy.

Additionally, by using the Autoconf/Automake tools, you could simply
specify a macro rule telling configure that you wanted to simply locate
certain required software like ipvsadm within a configure.in file:


Then, if ipvsadm were installed someplace else than where RH normally
expects it, configure would find it, and if it didn't, building would fail.
That way, you the software maintainer can dictate dependancies, while the
installer can dictate preferences.

At the very least though, this should be a Makefile option so the installer
of the software can easily change the location of where to look for certain

Note You need to log in before you can comment on or make changes to this bug.