From owner-freebsd-current Sat Aug 2 15:15:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA17913 for current-outgoing; Sat, 2 Aug 1997 15:15:21 -0700 (PDT) Received: from genghis.eng.demon.net (genghis.eng.demon.net [193.195.45.10]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id PAA17874 for ; Sat, 2 Aug 1997 15:15:01 -0700 (PDT) Received: from genghis.eng.demon.net [193.195.45.10] by genghis.eng.demon.net with esmtp (Exim 1.62 #1) id 0wumRi-0000B3-00; Sat, 2 Aug 1997 23:14:46 +0100 To: hoek@hwcn.org cc: current@freebsd.org Subject: Re: ports-current/packages-current discontinued Organization: Demon Internet Ltd. Reply-To: ade@demon.net In-reply-to: Your message of "Sat, 02 Aug 1997 17:27:48 EDT." Date: Sat, 02 Aug 1997 23:14:46 +0100 From: Ade Lovett Message-Id: Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [Followups to -current only, attempting to keep the discussion in one place] Tim Vanderhoek writes: > >Meta-ports!! Their time has come! > >Not only could meta-packages answer bloatist concerns that "an >installed FreeBSD system is useless unless one adds 1001 extra >packages", but they could provide increased flexibility. Actually, I don't think we need to go as far as meta-ports insomuchas implementing a separate concept, rather we build in the concept of dependencies into ports (both in binary and source form). Example 1: I want to compile cvsup from source, which requires modula-3. The make process sees checks to see if I have a modula-3/binary package installed, if not, then it uses the default rule to create modula-3/binary, giving me the option of either ftp'ing (or whatever) the /binary version, or building from the /source version. Once all dependencies have been satisfied, it then goes on to register cvsup/source in my package tree (since I've ftp'd it from somewhere), builds cvsup/binary and registers and installs that. Example 2: I want to install a full FreeBSD binary system (lets say 2.2.2-RELEASE). The actual initial install process only installs a minimal system, but then also has an "extras" /binary package, which builds nothing itself, but has a whole host of dependencies for perl/binary, tcl/binary etc.. etc.. which it then proceeds to install from ftp, cdrom, floppy etc. Nothing particularly world-crushingly-new here, but the concept of full packaging, with proper interdependencies, version numbering etc does have a certain appeal to it. Of course, there are a whole load of examples of how packaging has failed miserably, or is unusable, etc.. but even a cursory look at such afflicted systems will show that it's the implementation of packaging that's at fault, rather than the idea. Packaging most certainly is not a global panacea, and there are a whole host of issues that would need to be addressed at a very early stage to ensure that we don't end up shooting ourselves in the foot, but the concept does have a certain charm to it. Is this kind of thing worth investigating in more detail? -aDe -- Ade Lovett, Demon Internet Ltd.