From owner-freebsd-ports@FreeBSD.ORG Fri Dec 14 02:13:33 2007 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 354E616A419 for ; Fri, 14 Dec 2007 02:13:33 +0000 (UTC) (envelope-from danny@ricin.com) Received: from smtpq2.tilbu1.nb.home.nl (smtpq2.tilbu1.nb.home.nl [213.51.146.201]) by mx1.freebsd.org (Postfix) with ESMTP id C4AA813C455 for ; Fri, 14 Dec 2007 02:13:32 +0000 (UTC) (envelope-from danny@ricin.com) Received: from [213.51.146.188] (port=34187 helo=smtp3.tilbu1.nb.home.nl) by smtpq2.tilbu1.nb.home.nl with esmtp (Exim 4.60) (envelope-from ) id 1J303P-000720-5a for freebsd-ports@freebsd.org; Fri, 14 Dec 2007 03:13:31 +0100 Received: from cp1228410-a.dbsch1.nb.home.nl ([84.27.157.163]:51929 helo=desktop.homenet) by smtp3.tilbu1.nb.home.nl with smtp (Exim 4.60) (envelope-from ) id 1J303O-00056d-Kj for freebsd-ports@freebsd.org; Fri, 14 Dec 2007 03:13:31 +0100 Received: by desktop.homenet (sSMTP sendmail emulation); Fri, 14 Dec 2007 03:12:47 +0100 From: "Danny Pansters" To: freebsd-ports@freebsd.org Date: Fri, 14 Dec 2007 03:12:47 +0100 User-Agent: KMail/1.9.7 References: <475F7390.9090509@gmail.com> <0F330142-A3CA-4E6E-84BD-FDE55A8E3AEE@yahoo.com> <20071213111050.O6078@wonkity.com> In-Reply-To: <20071213111050.O6078@wonkity.com> X-Face: (Zs+'ncTcchkOX|~t6{?Iii=O!G#WEK!+OD0|-F=i%1pvP5V_Sz4PaJC8o)=?utf-8?q?MiSnH/JMJFy=0A=09oBN-My?=, v":S7, (=?utf-8?q?mmkPm=27U=7BMgT+eM=2EBd=5Cp/P!dr=5DhOTXqpse21O!=25Ct=60SE=2EOodq?= =?utf-8?q?=5Dry=5E=23kU=5E=0A=09-?=GT.[8D}i$6P>=" =?utf-8?q?=23=0A=09*J+4d=7E?= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712140312.47837.danny@ricin.com> X-Spam-Score: 0.0 (/) Subject: Re: Limitations of Ports System X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 02:13:33 -0000 On Thursday 13 December 2007 19:17:34 Warren Block wrote: > On Thu, 13 Dec 2007, Steven Kreuzer wrote: > > This thread was called "results of ports re-engineering survey" but I > > figured I would start a new thread. > > Rightly so. > > > On Dec 12, 2007, at 6:45 AM, Ade Lovett wrote: > >> We *know* it can be done better. We *know* the scaling limits of the > >> current system, and most of us are completely amazed it even still > >> works. > >> > >> If y'all want to make a difference, concepts and ideas we have plenty > >> of. Code talks. > > > > Out of curiosity, are any of these shortcomings documented anywhere? I > > have been using ports on my home machine for a long time and I've never > > had any problems with it. I assume the issues come into play when you > > work with multiple systems you are trying to keep in sync, etc. > > > > I would be interested in reading about some of the limitations people > > have run into when using ports. > > Notable with the new modular Xorg is the speed of changes > (install/deinstall/clean) when there are a lot of ports installed. > Before modular xorg, 400 ports installed was a lot. 700 now is not > surprising. > > Some profiling looking for areas which could benefit from speed > optimization would be useful. That may have already been done but not > publicized. > Well, I can tell you what I think: If we don't want thousands of global knobs, then it's either splitting up in almost atomic micro ports which inflates the number of ports or using port OPTIONS... BUT... we currently have no standard mechanism to actually use another port's OPTIONS in a somewhat generic way. It's all about where and how you want to have your granularity (sp?) I think. In the longer run, being able to specify a port's options when specifying DEPENDS would probably be a very useful and not very invasive change for the better (or maybe if that's simpler -- doubt it -- some sort of OPT_DEPENDS). If someone wants to work specifically on addressing - to put it bluntly - the "debianizing-ports-versus-optionifying-properly" issue I'm interested in chipping in or if needed leading such an effort. The scope should be only that and it must be backwards compatible. Some food for thought maybe, Dan