From owner-freebsd-ports@FreeBSD.ORG Fri Dec 14 03:35:59 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 611E716A46B for ; Fri, 14 Dec 2007 03:35:59 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.freebsd.org (Postfix) with ESMTP id 1FE6113C51B for ; Fri, 14 Dec 2007 03:35:58 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so766244pyb.3 for ; Thu, 13 Dec 2007 19:35:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=glvuJiRkyq3h4n6n9pQjhBSSYQHfcaj9ZNgfkWzphEA=; b=Am15QmyvevO9kz5CACEE5iXy7eB5G8fGNqOrdTbLRFMaAhtQM+sEEtSWPjSxgQ7HrMtOFfsPfGmfT6lMbX4Vm8VN2f5VeOH2uxbnpic+mMuK5w4YZSSM8a5HIBeRA/RIylFqDdYoeRJ5+ZzjmCZeeLC5AT8N3oUuwC108twBsB8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=f2F0miQZBvO4yO/iprjncig6D8NWMmmeZnBc18vdYtw6pKFNspIx2oedIxLY4UJuXLzDOO7lcvpsePtiPNLIF1jwAEjEmAs0/cJhG58Sz8uH+EF+fSDwljXMLtuUtYekWyE9kCW7g25TVskxc8yvyuRwQ5JEH7VgWP+8lN/BJkQ= Received: by 10.65.115.4 with SMTP id s4mr5960449qbm.71.1197603357533; Thu, 13 Dec 2007 19:35:57 -0800 (PST) Received: from ?192.168.2.2? ( [67.85.89.184]) by mx.google.com with ESMTPS id f18sm547774qba.2007.12.13.19.35.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 13 Dec 2007 19:35:56 -0800 (PST) Message-ID: <4761F9E2.7090706@gmail.com> Date: Thu, 13 Dec 2007 22:34:58 -0500 From: "Aryeh M. Friedman" User-Agent: Thunderbird 2.0.0.9 (X11/20071209) MIME-Version: 1.0 To: Danny Pansters References: <475F7390.9090509@gmail.com> <0F330142-A3CA-4E6E-84BD-FDE55A8E3AEE@yahoo.com> <20071213111050.O6078@wonkity.com> <200712140312.47837.danny@ricin.com> In-Reply-To: <200712140312.47837.danny@ricin.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org 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 03:35:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Danny Pansters wrote: > 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. An other option is keep the knobs in a centeral DB but only ask for ones the port being currently being compiled requires and all other values are cached. Namely if I build abc with options 123 and 345 and def with 345 and 678 then 345 will be cached for def since we already set it for abc. > > 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. There is enough dependancy (and alt versioning) issues they must be addressed also. The alt versioning alone will require a complete redesign I think thus we mightest well throw in port/package interchangability. So I am leaning towards a ground up rewrite unless some can show how to get real dependancy management and alt. versions into the existing framework. Note neither should complicate the current system any more then absulutely needed and any such compilcation should be on the maintainers and portmgr only (hopefully none). -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYfnizIOMjAek4JIRAisNAKCQ2VZ2wibSFinuKAztxJlvI6dbPQCdEgbQ SnHPQr+mrf9aImgj8iL7ZMI= =RuoC -----END PGP SIGNATURE-----