From owner-freebsd-arch@FreeBSD.ORG Wed Mar 6 08:40:44 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7418BF11 for ; Wed, 6 Mar 2013 08:40:44 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 39353A22 for ; Wed, 6 Mar 2013 08:40:44 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id CD7167300A; Wed, 6 Mar 2013 09:41:21 +0100 (CET) Date: Wed, 6 Mar 2013 09:41:21 +0100 From: Luigi Rizzo To: Marius Strobl Subject: Re: revising sys/conf/files* dependencies Message-ID: <20130306084121.GA85685@onelab2.iet.unipi.it> References: <20130305083817.GD13187@onelab2.iet.unipi.it> <112844CF-69C3-49A3-8581-8EF2A7DA8E8A@bsdimp.com> <20130305211953.GA51357@onelab2.iet.unipi.it> <6A93AA58-713D-4C25-A512-6927E27C5DE1@bsdimp.com> <20130306010720.GA68018@alchemy.franken.de> <20130306061119.GA77841@onelab2.iet.unipi.it> <20130306083420.GJ955@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130306083420.GJ955@alchemy.franken.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 08:40:44 -0000 On Wed, Mar 06, 2013 at 09:34:21AM +0100, Marius Strobl wrote: > On Wed, Mar 06, 2013 at 07:11:19AM +0100, Luigi Rizzo wrote: > > On Wed, Mar 06, 2013 at 02:07:20AM +0100, Marius Strobl wrote: ... > > Marius, just to clarify: > > > > sys/conf/files has no reasonable way to express dependencies. > > Correct, as Warner already said, but what you propose isn't an > acceptable workaround. it wasn't my intention to propose a workaround, i only preferred a more useful (in my opinion) failure mode. But given that there is little feedback and no agreement i'll take back my proposal. thanks for the comments luigi