Whamcloud - gitweb
b=22281 refactor packaging and versioning
authorBrian J. Murrell <brian.murrell@oracle.com>
Tue, 2 Nov 2010 20:14:44 +0000 (04:14 +0800)
committerVitaly Fertman <vitaly.fertman@sun.com>
Thu, 4 Nov 2010 18:09:59 +0000 (21:09 +0300)
commitfd0bd149e66cbc06a17c372e159f9bfba024cc97
tree38162c8f91abedd6b296312625dd06ec4ccda04f
parentbb82568ca39a55bfdcf9977be972d1dea8a705e1
b=22281 refactor packaging and versioning

Configure "--with-dist" switch to optimize configure to do just
enough to enable "make dist" to work.  There is likely more optimizations
that could be done

Provide reasonable defaults for the --with-linux and --with-linux-obj
configure arguments.

The LB_BUILDID macro determines the BUILDID to be used in the resulting
packages.

The LB_DOWNSTREAM_RELEASE macro implements the --with-downstream-release
configure option for downstream packages to provide their own versioning
details

Many changes to support allowing packagers to define a value in the release
string.
- allow callers to tell rpm where to find the kernel source/headers and
  objects.
  - default to /lib/modules/$(uname -r)/build if not specified
    - XXX: this should probably be handled completely in configure
- allow callers to tell rpm what the release string should be set to
  - the spec will default to the value that configure uses currently if
    not specified
  - this allows both the release string used in Lustre and the Release:
    string used in the RPM to be in sync
- in the make rpms target, strip the configure arguments for --with-linux
  and --with-linux-obj and give them to rpmbuild via it's new switches
- also, pass the release defined by the main configure to the RPM spec for
  further consistency
  - XXX: it is questionable whether this in fact has any value
- put the "downstream release" right into the release as it is defined by
  by configure
- bring the ldiskfs spec more into sync with the lustre spec file

version_tag.pl/make_META.pl needed better support for git.
It also needed better support for transporting the information
available in a source code system into the tarball so that when
unpacked, where no sourcecode system was in place, the origins
of the code could still be determined.
Example output:
git: v1_8_3_RC1-g751b802-CHANGED-2.6.18-128.1.1.el5_lustre.1.8.0.50.20090302160821smp
cvs: b1_8-20100429144101-CHANGED-2.6.18-128.1.1.el5_lustre.1.8.0.50.20090302160821smp
When run in a tree from a tarball, the output will be composed
of the same tag and build id (hash or datestamp) as the source the
tarball came from, but will refelect whatever kernel the unpacked
source was configured with.
Rename the tree_status file to META.

There are times when the kernel should be rebuilt for all distros, but
other times only for certain distros.  Make the "all distros" case
easier than having to increment the version in all of the
build/lbuild-$distro files.

i=wangyb
i=mjmac

When the lustre-fix is .0, when a tag is made, it includes the .0 so
just drop it.

Only append the .$BUILDID to the $EXTRA_VERSION when $BUILDID is
actually not empty.  Otherwise we get a trailing ".".

It seems that the regex(7) used in bash's [[ ]] is not terribly
portable across bash versions.  SLES10 expects (, ), and | (at least)
escaped with \.  RHEL5 will accept them either escaped or not.
Ubuntu fails to match if they are escaped.

We need a more consistent test for being a subdir of Lustre.
Differences in how automake passes dirnames made the existing code
unpredictable.

When the tag format is vW_X_Y_Z and lustre-fix (Z) is _0 when a tag
is made, it includes the _0 so just drop it.

i=yangsheng
i=wangyb

The return code from git status seems to be not as one would expect
and it can return both 1 or 0 in a git repository.  So change up and
use git branch instead.
Simplify the logic around this determination as well.

Due to some unknown issue with using rpmbuild with the ldiskfs tarball
causing symbol mismatches, do the right thing instead and build ldiskfs
first and then build lustre with the external ldiskfs.

Right now the method for doing this is a bit hacky since we point lustre
at the ldiskfs rpm BUILD product.  The right fix is to make an
ldiskfs-devel RPM, which is a future enhancement of this work.

This also fixes two bugs with ldiskfs' external module support building.
One is that the external ldiskfs tree check was using a file that only
exists in ext3 and not ext4.  The second is that ldiskfs' configure was
not properly initializing ldiskfs_is_ext4 and instead depending on the
rpmbuild/configure caller to pass flags to tell it to build with ext4.

i=wangyb
i=minh
18 files changed:
autoMakefile.am
build/autoMakefile.am.toplevel
build/autoconf/lustre-build-linux.m4
build/autoconf/lustre-build.m4
build/lbuild
build/lbuild-oel5
build/lbuild-rhel5
build/lbuild-sles10
build/lbuild-sles11
ldiskfs/autoMakefile.am
ldiskfs/configure.ac
ldiskfs/lustre-ldiskfs.spec.in
lustre.spec.in
lustre/scripts/Makefile.am
lustre/scripts/version_tag-cvs.pl [new file with mode: 0644]
lustre/scripts/version_tag-git.pl [new file with mode: 0644]
lustre/scripts/version_tag-none.pl [new file with mode: 0644]
lustre/scripts/version_tag.pl