From owner-freebsd-ports Fri Sep 8 19:42:41 2000 Delivered-To: freebsd-ports@freebsd.org Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by hub.freebsd.org (Postfix) with ESMTP id C831537B449; Fri, 8 Sep 2000 19:42:38 -0700 (PDT) Received: from silvia.hip.berkeley.edu (sji-ca14-01.ix.netcom.com [205.186.215.1]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id WAA24448; Fri, 8 Sep 2000 22:41:58 -0400 (EDT) Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.11.0/8.11.0) id e892fS906547; Fri, 8 Sep 2000 19:41:28 -0700 (PDT) (envelope-from asami) To: Kris Kennaway Cc: Will Andrews , FreeBSD Ports Subject: Re: Ports Options Paper References: From: asami@FreeBSD.org (Satoshi - Ports Wraith - Asami) Date: 08 Sep 2000 19:40:59 -0700 In-Reply-To: Kris Kennaway's message of "Fri, 8 Sep 2000 19:08:32 -0700 (PDT)" Message-ID: Lines: 33 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * From: Kris Kennaway * Good idea :-) Unfortunately it make take a bit of work since it probably * has other infrastructural baggage which needs to be ported. We'll see. :) * I meant that the new version of the package can't carry information about * all possible children and which versions are compatible with it. An * installed package knows which installed packages depend on it, but not * whether they will work with the new version. I see what you mean now. Yes, that will be a problem, but I guess upgrading all depending children (maybe given as an option) will be good enough for most people. * > Does the NetBSD index contain information on necessary version ranges * > for dependencies too? If so, yes, that should work. * * I'm not sure - someone should look into it. Any takers? Any takers? Knu-san, weren't you looking into NetBSD pkgsrc recently? :) * If you're happy for maintainers to just create additional child ports * which set the relevant build option, then that's fine by me. We can always * come back to it later. Yes, this is exactly what I mean. This problem is orthogonal to the options stuff. We usually just set variables in slave ports today. If that changes to some options, people can still use it the same way (and I can happily build packages in parallel). Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message