From owner-freebsd-ports@freebsd.org Fri Feb 12 00:41:09 2016 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 82713AA4E4A for ; Fri, 12 Feb 2016 00:41:09 +0000 (UTC) (envelope-from freebsdml@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 58580ECF; Fri, 12 Feb 2016 00:41:08 +0000 (UTC) (envelope-from freebsdml@marino.st) Received: from [192.168.1.21] (248.Red-83-39-200.dynamicIP.rima-tde.net [83.39.200.248]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 22D1C43C9F; Thu, 11 Feb 2016 18:41:05 -0600 (CST) Subject: Re: Removing documentation To: Royce Williams References: <56B754A8.3030605@marino.st> <56BCE01D.4010701@FreeBSD.org> <56BCE218.40403@marino.st> <56BCEC5F.4020007@marino.st> Cc: Kevin Oberman , lev@freebsd.org, FreeBSD Mailing List From: John Marino X-Enigmail-Draft-Status: N1110 Message-ID: <56BD2A1E.1020706@marino.st> Date: Fri, 12 Feb 2016 01:41:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 00:41:09 -0000 On 2/12/2016 1:22 AM, Royce Williams wrote: > Is the abstraction is happening at the equivalent level here? The > platforms that I'm thinking of -- that appear to have already solved > this entire class of problem long ago -- feature wrappers around > apt-get, not wrappers around dpkg. I'm not a linux guy so those things don't mean much the me. The abstraction layer here is at the appropriate level. I'm not seeing this fragmentation problem you're talking about, at least not with the newer tools. > I'm advocating that we stop quasi-providing four different flavors of > apt-get. Until there is a single and official mechanism for both > dependency resolution and configuration option management, the > fragmentation remains. Why do you think this is the case? Ports defines the dependencies and pkg respects them. I'm not seeing where there more than one method here. What other ones are there? > If there were no ports system, and everything was package-driven, I'd > agree. Synth and its cousins exist because people work from ports -- > which means that dependencies matter. Synth exist because people are insisting to build from source (even irrationally) so they might as well do it correctly. The statement above doesn't have anything to do with Synth being a binary. If a shell script was so good, why is portmaster unmaintainable? > The laissez-faire "there's no requirement to build from ports" that > permeates FreeBSD is exactly what's wrong. The fact that half of the > documentation and quasi-official tools tell people "hey, use one of > these three ports management tools, or maybe packages, pick what works > for you -- oh, and be sure to check /usr/ports/UPDATING every time you > touch any port or package" is a deep symptom of this fragmentation. THERE'S NO REQUIREMENT THAT SOMETHING THAT BUILDS PORTS NEEDS THAT ITSELF IS BUILT FROM PORTS. You responded to something different. > Because FreeBSD software management itself is not purely package based. > > As long as the ports system exists (and I think it should!), the > management of compilation requirements -- especially for something > that might need to be bootstrapped early, like a software management > tool -- is a valid topic. Well, except *this* tool will never be in a "bootstrap" path. Above is completely irrelevant. Besides, if the base is built, ports work, period. There are no "compilation" requirements. > To be clear: except for the Ada/ruby/whatever dependency chain, my > beef isn't with Synth qua Synth. It's that every time we spin up Yet > Another Optional Software Management Tool, we fragment further. If > Synth becomes the holy grail of package management -- so compelling > that it becomes the only choice people would want to make, which is > what I think we need -- then it should become part of base. 1) you should focus on retiring the old tools 2) It will never be part of base 3) no ports tool has even been part of base 4) the "winner" will be determined by merit. If some people insist on using inferior/broken/obsolete/unmaintained tools it's their choice and problem. The majority will migrate naturally. This started because I think that if a tool is documented in handbook, it must be maintained (not part of base). I've got no issue with non-base software documented. I was saying that being in the handbook should have a required level of quality and abandoning it would cause the quality to fall under that level. John