This diff increases the chance of succesfully making a release without needing NOPORTS or NOPORTREADMES, even in the face of an inconsistent ports tree. EG in ports/audio/ extracted from ctm cvs-cur 7067: Makefile had SUBDIR+=ripit-atapi but ripit-atapi/ was already empty except for an empty files/ directory. That inconsistency broke make release. My patch should avoid similar future problems. (Historical note: By or before ctm cvs-cur 7073 the SUBDIR+= in ports/audio/Makefile was removed to match the empty ripit-atapi/ . But the older 4.2-WC-CDROM/Disc2/CVS-Repo/ports.tar.gz shows ports/audio/ripit-atapi/ with 11 files. ) Fix: Apply diff, (after removing some/all of comment block). How-To-Repeat: Create an inconsistent cvs/ports subdir with a SUBDIR+= pointing to an empty directory, then wait for cvs -P used below to prune the empty directory to non existance & then `make readmes` (from `make release` fails. (Note `cd ports/audio; make readmes` does not fail on mere empty directories, but as cvs fails to create an empty directory, make fails) su ; cd /usr/src/release ; make release CHROOTDIR=/a_dir_with_a_gig_free \ MACHINE_ARCH=i386 RELEASETAG=RELENG_4_2_0_RELEASE \ PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games \ CVSROOT=/usr1/cvs BUILDNAME=4.2-RELEASE
Responsible Changed From-To: freebsd-ports->jkh 'make realease' is Jordan's realm.
> Apply diff, (after removing some/all of comment block). This feature seems good, but I think it would be better that the default value of PREANPORTS is '-P'. However, I don't think this is the solution of "failing make readmes." It's a port's problem and that ports should be fixed instead of src/release/Makefile. Moreover, /usr/ports directory without preaning causes trouble to the users who installs ports.tgz; they will see lots of unwanted directories. Again, this is each ports problem; fixing src/release/Makefile is *not* a good idea. How do you feel about this, jkh? -- - Makoto `MAR' Matsushita
State Changed From-To: open->closed I don't think the problem should be fixed here since it's more of a procedural error than anything that this is trying to work around. People building releases should build from known-good snapshots of the CVS repository rather than simply hoping that something like "preening" will save them from transient states of badness - that's only a recipe for being lulled into a false sense of security.