From owner-svn-ports-all@FreeBSD.ORG Mon Jan 26 03:59:58 2015 Return-Path: Delivered-To: svn-ports-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9DB2A3F; Mon, 26 Jan 2015 03:59:57 +0000 (UTC) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B134B1D9; Mon, 26 Jan 2015 03:59:57 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id kx10so9352832pab.11; Sun, 25 Jan 2015 19:59:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HJokgoN+dcxp8S2o/htQvqIkqu/27AGF4twFVj6qMMk=; b=JkqnLWEHsCfoB/Cx0KVr0katg7/go/BBHZ40b7UZDeOAAOGM9wGM8ti6AlxDWJicJE kXdoo4PWuuqKweZ5Z04r8TQeAA4oWjEfKGItxEX38x2dTy24LnppwvF48UfUXy9m0r/u o2Fefy43G/L+kySoJtrJzAeenxvPHq//tMEh1Ozz9Kb4Kme2HkLXWf/vqnlo66p/kAlS HJ7DIrN+qKBT1glFYYzf1xj4543BoCJn2huoiUo95db4BChAnlsvzhCdYvlEf88T7eI0 LllwtRUQJ+8DjTs575PAwN027aYSUA3fUi8X/HPAug3t05vGOIWhmaKKkCPhun6MXEGy VDhw== X-Received: by 10.70.102.193 with SMTP id fq1mr31250486pdb.19.1422244797305; Sun, 25 Jan 2015 19:59:57 -0800 (PST) Received: from [192.168.1.107] (ppp59-167-128-11.static.internode.on.net. [59.167.128.11]) by mx.google.com with ESMTPSA id q10sm8491443pdm.78.2015.01.25.19.59.54 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Jan 2015 19:59:56 -0800 (PST) Sender: Kubilay Kocak Message-ID: <54C5BBB7.9070808@FreeBSD.org> Date: Mon, 26 Jan 2015 14:59:51 +1100 From: Kubilay Kocak Reply-To: koobs@FreeBSD.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: Alexey Dokuchaev , Lars Engels Subject: Re: svn commit: r377721 - in head/devel/newfile: . files References: <201501231039.t0NAdYS5095664@svn.freebsd.org> <20150123110243.GA64051@FreeBSD.org> <54C234F6.4070805@FreeBSD.org> <20150123122120.GA91455@FreeBSD.org> <54C3583E.1070205@FreeBSD.org> <20150124140220.GF67556@e-new.0x20.net> <20150125180426.GA11307@FreeBSD.org> In-Reply-To: <20150125180426.GA11307@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, Johannes Jost Meixner , ports-committers@freebsd.org X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 03:59:58 -0000 On 26/01/2015 5:04 AM, Alexey Dokuchaev wrote: > On Sat, Jan 24, 2015 at 03:02:21PM +0100, Lars Engels wrote: >> On Sat, Jan 24, 2015 at 07:30:54PM +1100, Kubilay Kocak wrote: >>> I'd like to enable easy discovery by users and better search relevance >>> by matching upstream names as closely as possible. [...] >>> >>> Other than the subjective prettiness factor, which I don't have a >>> position on, what technical considerations or issues are there, if any, >>> with dotted ports? >> >> There might be scripts which expect the first dot in the version part of >> a package's name and not in the name itself. > > Right, but not only that. I've mentioned that it had bitten us in the past > and digged these two commits: > > http://svnweb.freebsd.org/ports?view=revision&revision=288024 > http://svnweb.freebsd.org/ports?view=revision&revision=288046 > > One could argue if we should still care about defunct csup/cvsup or whether > "standard Unix file-cleaners will come through and nuke this directory", or > whether traditional concept of a "file extension" should affect directory > names, but IMHO all these illustrate fragility of dotted directories quite > clearly already. > > Even if one disagrees with my sens esthetique, the fact that dotted dirnames > did create problems in the past kind of suggests that they might pop up in > the future. Then again -- they are ugly; as Lars had mentioned, dots could > be expected to be used exclusively in versions; etc. -- better avoid to this > mess once and for all. I'll probably cook up a patch to PHB on this matter. > > ./danfe > I'm -1 on exception cases in general, and in this case in particular as it prevented us (Python) from improving consistency among a large set of ports. Beyond that, the broken tool argument suggests only exactly that, broken tools. It is the same argument to suggest that a broken HTTP parsing library used in a client for example, ought to be supported by coupling it to some arbitrary convention in response headers from our package servers. This of course is ridiculous. The software has now been fixed. There is no need to couple our conventions to the (flaky) programming practices of external software. The argument to aesthetics may be valid, but it is weak. It does does not warrant trumping convention/consistency of a third party software library (the ports framework) for third party software that we do not get a say in choosing the naming convention for. Our job is to support the growth of a ported software framework, nothing more.