From owner-freebsd-ports@FreeBSD.ORG Mon Nov 3 08:22:19 2014 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3363CC3 for ; Mon, 3 Nov 2014 08:22:19 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 32638B8C for ; Mon, 3 Nov 2014 08:22:18 +0000 (UTC) Received: from mandree.no-ip.org ([78.48.46.146]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MIuzJ-1Xn7e72yk5-002ZOv for ; Mon, 03 Nov 2014 09:22:10 +0100 Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id E0F8223D556 for ; Mon, 3 Nov 2014 09:22:09 +0100 (CET) Message-ID: <54573B31.7080809@gmx.de> Date: Mon, 03 Nov 2014 09:22:09 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-ports@freebsd.org Subject: Re: Reducing the size of the ports tree (brainstorm v2) References: <20141031185621.GC15967@ivaldir.etoilebsd.net> In-Reply-To: <20141031185621.GC15967@ivaldir.etoilebsd.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:J2UZ4Lkcz/0k9RmcxB5xxAZt2axyq93w5/mdW8altit62kkMAHf 5KrFhyzmVLWX/IE5zjUUqV7vhDZqKA4BzJpsI20TvGg6va79ZiORuQPoxPmGsbk6eBVWYlJ CndBpTplubmBdWIExcJ0nrkhcXe2fWIuZ4UcF2H9u7uMtsmLgaFbD7Nf8YCYu3nTzWwCOOS 8ueE2BS3o25p9L+afxoyA== X-UI-Out-Filterresults: notjunk:1; X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 08:22:19 -0000 Am 31.10.2014 um 19:56 schrieb Baptiste Daroussin: > Hi all, > > tijl@ spotted an interesting point, distinfo and pkg-descr files files > convenient are taking a lot of space for "free", we can reduce the size of the > while ports tree by a factor 2 by simply merging them into one of the other > files (Makefile and/or pkg-plist) from my testing it really devides > significantly the size of the tree. > > Problem is how to merge them if we want to. > > What we do not want to loose: > - Easyness of parsing distinfo > - Easyness to get informations about the description > > so far I have not been able to figure out a user friendly way > > Ideas I got so far only concerns pkg-descr: > Adding an entry in the Makefile for the WWW: > WWW= bla > or an entry in the plist: @www http... > > for the description the Makefile is not suitable as multi line entry in > Makefiles are painful > Maybe a new keyword: > @descr < mydesc > in > multiline > EOD > > which could easily be added to the plist parser in pkg. But I'm do not find that > very friendly in particular for make(1) to extract the data. > > Concerning the distinfo I have no idea. > > so this mail is a call of ideas :), if nothing nice ideas is found we will just > do nothing here :) My urgent recommendation is to leave it as is. Even if it wastes 200 MB. Space is so cheap these days it's not worth introducing new instabilities, re-train all contributors and all that. We haven't even shaken off all the staging and pkg fall-out, and now we're talking about the next revolution. And if we really decided that we want to change things, we would need these things BEFORE the implementation: 1. a clear list of the problems. 1a. Space does not count, see above. 1b. Insufficient tools (SVN) do not count. If the tools are bad, we need other tools, not change our way of doing things. 2. a clear list of requirements what the solution is to achieve 3. only then can we start implementing. What you're proposing is a solution without a clear plan of what it's supposed to solve, and how. And IF we still decided the current way of things is so painful we need to do something, we should leverage some of the existing extensible forms; XML, JSON, ... diverse other markup languages. Let's not cook something new on our own if we already have tools for established markup.