From owner-freebsd-testing@FreeBSD.ORG Mon Oct 28 23:57:12 2013 Return-Path: Delivered-To: freebsd-testing@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2B751DE7; Mon, 28 Oct 2013 23:57:12 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EF09529A9; Mon, 28 Oct 2013 23:57:11 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id w10so5970756pde.17 for ; Mon, 28 Oct 2013 16:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k0ahKReJ44GiPenAeafK/TPiSiFy9WFqDSFS9jDZdw8=; b=eHi1Tk7I4sd+xrXbSvFHb44ypXewPAX3cviiNCWfezxlbdN1Ct0RKf6KQIzSnNXrCi OeBJoiHhSTiboBwtO0fWFyQqiXQn5Zcr+Hk3rD3E75I/wf/+cwyOmrkrzJXxQIy5PB/w +1i2ecjA47vnudKeWj1HazwewxoL9cWyRsScz21vJXIlsJIZqo04e5vyecVW3xCnxvYd ZHM4tACPG0sgC/Wyh/I3dczYAURvsAIuFWbHgOXXhCDQ0Ampbm+0/BUF53tmuEFebCQA 7nmKqDY2hYPcwsm8CpeE10syBbh+m+AK5djCIXmwS9H4moTWLbpXx6XgaJFF1qL6J9rf tbmA== X-Received: by 10.68.253.67 with SMTP id zy3mr5644426pbc.137.1383004631540; Mon, 28 Oct 2013 16:57:11 -0700 (PDT) Received: from [10.0.1.195] ([64.14.143.130]) by mx.google.com with ESMTPSA id y9sm38140197pas.10.2013.10.28.16.57.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Oct 2013 16:57:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Plugging ATF tests into the build and other cleanups From: Garrett Cooper In-Reply-To: Date: Mon, 28 Oct 2013 16:58:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Julio Merino X-Mailer: Apple Mail (2.1510) Cc: freebsd-testing@freebsd.org, Baptiste Daroussin , Rui Paulo , Simon Gerraty X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 23:57:12 -0000 On Oct 27, 2013, at 6:31 PM, Julio Merino wrote: > On Sun, Oct 27, 2013 at 8:25 PM, Eitan Adler = wrote: >> On Sun, Oct 27, 2013 at 6:12 PM, Julio Merino = wrote: >>> Hello! >>> The one concern I have here is having to keep track of all tests in >>> tools/build/mk/OptionalObsoleteFiles.inc so that setting >>> WITHOUT_TESTS=3Dno cleans up /usr/tests. This will be a pain to = maintain >>> and a sure source of inconsistencies. If we could special-case this = to >>> make it more automatic, do you have any suggestions? >>=20 >> Is it possible to use the list of current tests and just delete any >> files which are not listed? >=20 > I think what you are suggesting applies to src/ObsoleteFiles.inc, not > tools/build/mk/OptionalObsoleteFiles.inc? Yes. > For deleted tests, I think using src/ObsoleteFiles.inc is fine as > usual. Deleted tests have to be removed no matter what the value of > MK_TESTS is. If that list gets out of hand at some point we could > revisit this, although I'm not sure how you can easily determine the > list of "current tests". AFAIK there is no list in src detailing all > files that are expected to be installed? >=20 > My concern is only about the latter at the moment. When MK_TESTS=3Dno, > /usr/tests should not exist at all and, therefore, a "make > delete-old-files" should wipe it. We can do this as usual, with the > functionality in tools/build/mk/OptionalObsoleteFiles.inc to record > all files to be deleted, or we can do something different to avoid > maintaining the list by hand. A simple "rm -rf ${DESTDIR}/usr/tests" > would suffice, but I'm just wondering if that'd be an acceptable thing > to do. This could delete local files though, unexpectedly.. What if you were = doing local hacking and your tree was blown away for instance? make = delete-old* protects against that today. This point might be a good point to bring up standardizing packaging in = base; I have an idea of how to design this from a make perspective after = dealing with this pain ad nauseam for Isilon--just wouldn't want to do = the work if another effort was underway. I realize this is an orthogonal = goal, but it would simplify this a lot -- I found it an incredibly pain = in the rear trying to figure out the ad hoc release "packaging" system = and how to make tests fit on release ISO images a few months back. I've = CCed bapt@ just in case; I know that bdrewery is on this list and he = might have some input to provide. Thanks! -Garrett=