From owner-freebsd-ports@freebsd.org Thu Aug 31 20:19:47 2017 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 87BF0E05200 for ; Thu, 31 Aug 2017 20:19:47 +0000 (UTC) (envelope-from rde@tavi.co.uk) Received: from kipling.tavi.co.uk (kipling.tavi.co.uk [81.187.145.130]) by mx1.freebsd.org (Postfix) with ESMTP id 3AB7B65E2B for ; Thu, 31 Aug 2017 20:19:46 +0000 (UTC) (envelope-from rde@tavi.co.uk) Received: from kipling.tavi.co.uk (localhost [127.0.0.1]) by kipling.tavi.co.uk (Postfix) with ESMTP id B49AE892BD for ; Thu, 31 Aug 2017 21:12:08 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=tavi.co.uk; h=date:from:to :subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=selector1; bh=JZhd2Jp ZHwkd3m6vil2aneZ5poc=; b=rOimvv+5Vt3EQbaNaHp9kCYRL0ksIP0V6iHo3JK tXJ4+E45RsxGmN6KmpMb3HJXLwQOet2Xj6KWNsBG/4dCMz2g0Ei8IKoN9jcBVkk/ YJZn4k3g8bPJIn6puY/0x+cS/6TYHQ8EfO3KhIjboYtO4vki7zupkmbH+Bl1hbyS Fimc= Received: from raksha.tavi.co.uk (raksha.tavi.co.uk [81.187.145.139]) (Authenticated sender: rde@tavi.co.uk) by kipling.tavi.co.uk (Postfix) with ESMTPA id 6179E892BA for ; Thu, 31 Aug 2017 21:12:08 +0100 (BST) Date: Thu, 31 Aug 2017 21:12:08 +0100 From: Bob Eager To: freebsd-ports@freebsd.org Subject: Re: standard locations for port files Message-ID: <20170831211208.30cdc328@raksha.tavi.co.uk> In-Reply-To: <76pgqcptlcrvhuavu1bquknbbdfr8n0cdf@4ax.com> References: <59A82622.4030502@gmail.com> <729F1CC6-9A65-4CDF-B7E5-FB520779FD15@adamw.org> <76pgqcptlcrvhuavu1bquknbbdfr8n0cdf@4ax.com> X-Mailer: Claws Mail 3.15.0 (GTK+ 2.24.31; i386-portbld-freebsd11.0) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAMFBMVEUwXjFLc0vD0cS7y7zw9PDZ4tkWSRaVrZZ+m39qi2tXfVj////7+/utwK4IPggAOAAJUUA7AAABKklEQVQ4jWPYjQMwDFYJp0NKEKCNJmEf9h8CsimXiL2e33s3/e7F7K2Cs3f3dCMkQkMKj4YuCY3K3iR+e7fMaiSjvkX0/5cFGrWpe2uLzOpaExUVqMS/8PX/Re5ey960OLBTZpFA8+IlSBKPQ92zNyUUBsosN58uIY0k8f+/ONCoYytkVuhWzVwNkYiYbqk5M3NmOVBi41YZ8RsGF7shEtFb5KJ3r969CyixM7OTPeFUxG2IxLO8/9/SvqXlc+/x3h295YzLlj2nIRJQj//nRvc5TEIal8RsXBLVuCQwIgoq/u80DomP6HEOk/iOS+IJLonZOCT+ReOQ+Lkbh0QKLonbOCR+7MYhsRqHBJrVcIl/1TgklqKLQyQ+tGKIgyQOqXpjig94diZRAgAXmDX6jyWafAAAAABJRU5ErkJggg====== MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 20:19:47 -0000 On Thu, 31 Aug 2017 15:54:09 -0400 wrote: > [Default] On Thu, 31 Aug 2017 13:53:27 -0500, Adam Vande More > wrote: > > >On Thu, Aug 31, 2017 at 1:41 PM, wrote: > > > >> Why wouldn't logs be in /usr/local/var/...? Given that all > >> other port "stuff" is under /usr/local, what advantage is there > >> in making logs an exception? > >> > > > >Because logs shouldn't be under /usr. > > Why not? The current location wasn't determined by natural law, > it was just someone's decision, almost certainly made without > much thought at all. It could be re-decided just as easily. The current hierarchy has had a lot of thought put into it. Files in /usr generally don't constantly change (although if /home is symlinked to /usr/home they might, I guess. Files in /var *do* change a lot, hence its name. It's also the reason that the root file system is separate; if it isn't written to much, it's less likely to sustain damage. /var is designed for files that *change* - that's why logs go there. If you want to, by all means create /var/local and put your logs there. A compelling reason, already mentioned, is that there are a lot of systems that have /usr mounted read only (e.g. net booted systems, or those that are booted from a USB stick). Such systems usually put /var in a RAM disk, so that logs can be kept. Even if /var is on an actual disk, it means that other parts of the file system can be kept read only. This improves reliability and integrity, and makes recovery after a crash a lot quicker. All in all, /var is the *right* place.