svn commit: r422160 - in head: chinese/fortune french/fortune-mod-zarathoustra misc/fortune-mod-bible misc/fortune-mod-bofh misc/fortune-mod-culmea-culmilor misc/fortune-mod-epictetus misc/fortune-...

[John Marino]

On 9/14/2016 15:57, Bryan Drewery wrote:
> On 9/14/16 1:45 PM, Adam Weinberger wrote:
>>> On 14 Sep, 2016, at 13:50, Antoine Brodin <antoine at FreeBSD.org> wrote:
>>>
>>> Author: antoine
>>> Date: Wed Sep 14 19:50:46 2016
>>> New Revision: 422160
>>> URL: https://svnweb.freebsd.org/changeset/ports/422160
>>>
>>> Log:
>>>  Revert recent strfile changes, strfile is already in base
>>>
>>>  With hat:	portmgr
>>
>> John's changes did have merit---not everybody has the games distribution
>> installed.
>>
>
> You could say this about every option in base.  That does not justify
> adding everything in base into the ports tree again.  It means the user
> should enable that option in base if they want that functionality.  We
> really do not need 2 versions of strfile, which has gone unchanged for a
> long time.
>
> Optional pieces of base being in ports make sense when they are getting
> frequent updates, such as Kerberos or OpenSSL or OpenSSH.
>
> If a user wants these game ports, they would want the game distribution
> in base as well, so they should already have strfile.
>
> The truth here seems to be closer to that this is just for DragonFly.
>
> My large vision is that we move a lot of base into "ports"/packages (not
> what we have today).  In that case we would have just 1 version of
> OpenSSL, fortune, strfile, etc.  In that world we move/merge most of
> base with their port versions.  We're not anywhere near that today.
>
> Now, removing the games from base entirely and moving them to ports is a
> different discussion.  I personally am open to that, but not duplicating
> everything for the sake of non-default setups without frequent updates.
>
>> Perhaps a Uses/strfile.mk would be better here? It could allow for
>> /usr/bin/strfile or /usr/games/strfile if they exist, or depend on the strfile port otherwise. Best of both world and everybody wins.
>>
>
>

this is all ridiculous.
It's a 400-line C program that is strictly a BUILD_DEPENDS.
It caused no significant burden and solved problems.
Ports have gone unmaintained for YEARS but somehow you can justify 
deprecating this one in 3 hours, and then claim you are treating all 
ports the same.  You just aren't.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus