Bug 236032

Summary: provide build version, flags, configure args, env, and components at runtime
Product: [Retired] 389 Reporter: Rich Megginson <rmeggins>
Component: Directory ServerAssignee: Bob Lord <blord>
Status: CLOSED WONTFIX QA Contact: Chandrasekar Kannan <ckannan>
Severity: low Docs Contact:
Priority: low    
Version: 1.0.4CC: benl, rmeggins
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-08-24 23:04:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 152373, 434915    

Description Rich Megginson 2007-04-11 16:19:30 UTC
When we build the directory server, we should store the following information
and make it available at runtime:
* version number including any patch/hotfix/alpha/beta version information
* the arguments to the configure command - this may include explicit switches on
the configure command line such as --with-fhs, and environment variables set
that affect configure such as CFLAGS=-xarch=v9
* a list of all of the components used to build the product - this list should
include the exact version and possibly the md5sum of key files used in the component

I'm not sure what file format to use.  There may already be a convention used in
other projects.  Ideally, this information would be printed by the server itself
e.g. I should be able to do ns-slapd --buildinfo (we already use -v and -V for
other things) and have it print out this information.

In the absence of a pre-existing convention for this type of information, I
think /usr/share/<packagename> should be the directory used, and this directory
will contain a file called buildinfo.<uniqueversion> where <uniqueversion> is
the unique numeric version string.

Note that if it is not possible to distinguish between environment variables
that affect configure/make and those which do not, we should just dump all
environment variables passed to configure and screen out those that may contain
sensitive information (e.g. USER, HOME, etc.)