From owner-freebsd-ports@FreeBSD.ORG Sun Apr 2 21:29:19 2006 Return-Path: X-Original-To: freebsd-ports@freebsd.org Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C18EA16A420; Sun, 2 Apr 2006 21:29:19 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: from mx1.highperformance.net (ip30.gte215.dsl-acs2.sea.iinet.com [209.20.215.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 293A943D49; Sun, 2 Apr 2006 21:29:16 +0000 (GMT) (envelope-from jcw@highperformance.net) Received: from [192.168.1.16] (w16.stradamotorsports.com [192.168.1.16]) by mx1.highperformance.net (8.13.4/8.13.4) with ESMTP id k32LTV04015852; Sun, 2 Apr 2006 14:29:31 -0700 (PDT) (envelope-from jcw@highperformance.net) Message-ID: <44304219.5070300@highperformance.net> Date: Sun, 02 Apr 2006 14:28:57 -0700 From: "Jason C. Wells" User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Tom McLaughlin References: <200604021324.k32DOU5E077448@hardy.tmseck.homedns.org> <1144009291.1978.105.camel@bofh> In-Reply-To: <1144009291.1978.105.camel@bofh> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=2.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on s4.stradamotorsports.com Cc: pav@freebsd.org, freebsd-ports@freebsd.org, Thomas-Martin Seck Subject: Re: Pare Down Dependencies from Gnome 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: Sun, 02 Apr 2006 21:29:19 -0000 Tom McLaughlin wrote: > (If someone is looking for something to do, trying working out an easy > way to handle all three versions of Kerberos in a uniform way within the > ports tree and avoids the hassles people often run into when using > versions from the ports tree.) This is a specific case of a more general problem. Try to work out an easy way to handle port dependencies when disparate versions, configurations, and implementations of a particular library or protocol exist and have many to many relationships to independent ports throughout the ports tree. These relationships must maintain consistency automagically without communication between various port maintainers and users. I'll have the solution to you in 23 minutes. :) It seems that the ports system might make use of a substitution matrix for those ports/libraries/chunks of base. Such a system might have an primary attribute called an interface. The interface might have one or more implementations (e.g. MIT Kerberos, Heimdal, or perhaps perl-5.8.[5,6,7,8,foo]-[threaded]). An interface might be a library, service, or protocol. A potential port would get check if the interface existed on a system. Leave the port ignorant about the implementation specifics of a particular interface. Did I mention that I am not a hacker? What I am proposing is to add a level of indirection to the ports system. Don't depend on a port. Depend on an interface. Later, Jason C. Wells