Subject: misc/11486: 'make release' does an 'rm -rf $RELEASEDIR' with no way to override
To: None <gnats-bugs@gnats.netbsd.org>
From: None <John.P.Darrow@wheaton.edu>
List: netbsd-bugs
Date: 11/13/2000 15:04:30
>Number:         11486
>Category:       misc
>Synopsis:       'make release' does an 'rm -rf $RELEASEDIR' with no way to override
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    misc-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Mon Nov 13 15:01:01 PST 2000
>Closed-Date:
>Last-Modified:
>Originator:     John Darrow
>Release:        NetBSD 1.5_BETA2 2000-11-11, also on 1.4 branch, probably current too
>Organization:
Computing Services, Wheaton College, Wheaton, IL
>Environment:
System: NetBSD jdarrowpiii.wheaton.edu 1.5_BETA2 NetBSD 1.5_BETA2 (JDARROW) #0: Fri Nov 10 17:39:52 CST 2000     jdarrow@jdarrowpiii.wheaton.edu:/var/src/sys/arch/i386/compile/JDARROW i386

>Description:
	Running a 'make release' in /usr/src or /usr/src/etc unconditionally
does a '/bin/rm -rf ${RELEASEDIR}' in etc/Makefile:snap_pre, with no way to 
override it.  This is BAD if, for example, you've just done a 'make release'
in /usr/xsrc, because now you just lost those lovely x sets you built to
go with your main sets.  This can be even worse if, for example, you
prebuilt those sets because you don't have enough disk space for a complete
snapshot of both src and xsrc at the same time, because now you may have to
reinstall xsrc and rebuild to get those sets back.
>How-To-Repeat:
	cd /usr/xsrc; make DESTDIR=/altroot RELEASEDIR=/whatever release
	cd /usr/src; make DESTDIR=/altroot RELEASEDIR=/whatever release
	install on another machine, watch sysinst complain about missing
sets upon reaching attempt to extract xbase.tgz.
>Fix:
	Either remove this 'rm -rf', and let the user rm -rf the directory
beforehand if they really need to, or at least allow the user to set a make
variable (something like NO_RM_RELEASEDIR) to prevent the removal.
	(Please note that the fact that we've already had to deal with
problems with this barfing when ${RELEASEDIR} is a mount point supports the
argument that this unconditional rm is not a good idea...)
>Release-Note:
>Audit-Trail:
>Unformatted: