Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 236032 - provide build version, flags, configure args, env, and components at runtime
Summary: provide build version, flags, configure args, env, and components at runtime
Alias: None
Product: 389
Classification: Retired
Component: Directory Server
Version: 1.0.4
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bob Lord
QA Contact: Chandrasekar Kannan
Depends On:
TreeView+ depends on / blocked
Reported: 2007-04-11 16:19 UTC by Rich Megginson
Modified: 2015-01-04 23:25 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-08-24 23:04:42 UTC

Attachments (Terms of Use)

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.)

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