svn commit: r377721 - in head/devel/newfile: . files

[Kubilay Kocak]

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.