From owner-freebsd-ports Sat Sep 9 7:16:53 2000 Delivered-To: freebsd-ports@freebsd.org Received: from ns1.sunesi.net (ns1.sunesi.net [196.15.192.194]) by hub.freebsd.org (Postfix) with ESMTP id 8573D37B422 for ; Sat, 9 Sep 2000 07:16:49 -0700 (PDT) Received: from nbm by ns1.sunesi.net with local (Exim 3.03 #1) id 13XlQo-000IVQ-00; Sat, 09 Sep 2000 16:16:34 +0200 Date: Sat, 9 Sep 2000 16:16:34 +0200 From: Neil Blakey-Milner To: Steve Price Cc: Will Andrews , FreeBSD Ports Subject: Re: PortsNG (was Re: Ports Options Paper) Message-ID: <20000909161633.A71013@mithrandr.moria.org> References: <20000903052226.E1205@radon.gryphonsoft.com> <20000909003743.B92984@bonsai.hiwaay.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000909003743.B92984@bonsai.hiwaay.net>; from sprice@hiwaay.net on Sat, Sep 09, 2000 at 12:37:43AM -0500 Organization: Sunesi Clinical Systems X-Operating-System: FreeBSD 3.3-RELEASE i386 X-URL: http://rucus.ru.ac.za/~nbm/ Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat 2000-09-09 (00:37), Steve Price wrote: > Please let's forget about the 10 perl scripts, 3 acts of congress, and > 2 acts of God for a few minutes. Let's define the problem fully first > and then start talking about ways in which we can address them. I have > a feeling that we'll come up with several distinct tasks that we can design > together and code in parallel. For instance, we'll probably end up > needing a better (read, more flexible) package format in the long run, > but we must define our expectations of it before we jump in and start > coding it otherwise we'll be back here next year doing the same thing. > If we ever get through hacking hacks that is. Firstly, I'm only responding to things that come directly to mind immediately, and if I don't respond to something, you can be sure you've got me thinking deeply. I'm pondering setting up a Wiki-like system to describe what we all want, and how we each thinks it can be achieved, and what background materials we make these assumptions from - OpenBSD ports, NetBSD pkgsrc, Debian's dpkg/apt system, &c. I don't think the package format is in the least significant to the problem, except possibly the use of zip-like archives to only grab headers, and to perform some sort of package signing. These are both dealt with in the package format described and implemented in libh currently. > Sounds pretty easy so let's take this one step further. Let's suppose > the same libfoo port is updated to a new version and now can also be > built WITH_ICK. Here's where it gets tricky. Are WITH_BAR and WITH_ICK > mutually exclusive or can both of them be on at the same time? If the > former then the new system needs to have the smarts to recognise that > there is a conflict and do 'something' about it. In the latter case > we need to have in place the infrastructure to build libfoo, libfoo_bar, > libfoo_ick, and libfoo_bar_ick. One unexplored bit of functionality I had in my portconf dashboard a year and a half ago required "multiple packages from one port", in that it was an auto-explore on all the available options (that affected the build) and generating a package with each set of compatible options: { { !foo, !bar, !baz }, { !foo, !bar, baz }, { !foo, bar, !baz }, { !foo, bar, baz }, { foo, !bar, !baz }, ... } I think this may be overkill, but it's probably something that can easily be implemented in an automatic way, and definitely something that can be implemented in a manual way (cf. OpenBSD flavours, portconf 'classes') even in the one-port-one-package way. > Things like this are what we *must* nail down before we to decide to > pilfer, purchase, or code it ourselves. Am I the only one that feels > this way? The way things usually work is: a) You provide thoughts, and no code, and you're told you're just talking hot air, and that you're an arm-chair general, and that you don't understand all the implications; b) You provide the code, but no documentation, and you're told that the change requires documentation and a design document, and that you're just hacking, and that without the design doc, you can't possibly understand all the implications; c) You provide code and documentation, and you get no feedback. Neil -- Neil Blakey-Milner Sunesi Clinical Systems nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message