cvs commit: src/sys/conf newvers.sh

Colin Percival cperciva at freebsd.org
Fri Aug 19 15:50:45 GMT 2005


Doug Barton wrote:
> 1. A "better" way (IMO) to write:
> 
> if [ "X${BRANCH_OVERRIDE}" != "X" ]; then
> 
> is
> 
> case "${BRANCH_OVERRIDE}" in
> '')    ;;
> *)    BRANCH=${BRANCH_OVERRIDE} ;;
> esac
> 
> The original reason for writing it this way was to avoid the call to
> test(1), because case is a shell builtin. This is a style issue, and not
> a "must have," but I thought I'd mention it.

I couldn't see anything in style(9), so I just wrote it the way I've
seen most often in the FreeBSD tree; but it's good to now know _why_ I
keep on seeing it written that way. :-)

> I like your override idea here, but I'd rather not have to keep track of
> what the current value of $BRANCH is so that I can include it in my own
> override variable. What would be more useful to me (and arguably more
> useful in general, although once again I will not press the point) would
> be some way to add a string to the BRANCH or RELEASE variables.

That wouldn't be sufficient for the purpose I have in mind.  When running
FreeBSD Update builds, I'll typically have a RELEASE-pX tree checked out
and a security patch (which is going to get committed to the tree later);
I want to be able to build tree + patch with a label of RELEASE-p{X + 1}.

Of course, I could do this by applying an extra patch to the source tree
before building, but the whole idea is to get rid of the local patches
which I've been carrying around in FreeBSD Update.

> 3. Even in the hectic environment leading up to a release, I dislike
> insta-MFCs.

Understood.  If the -BETA3 builds hadn't been starting soon, I'd have waited
the usual 72 hours.

Colin Percival


More information about the cvs-all mailing list