Date: Sat, 02 Aug 1997 23:14:46 +0100 From: Ade Lovett <ade@demon.net> To: hoek@hwcn.org Cc: current@freebsd.org Subject: Re: ports-current/packages-current discontinued Message-ID: <E0wumRi-0000B3-00@genghis.eng.demon.net> In-Reply-To: Your message of "Sat, 02 Aug 1997 17:27:48 EDT." <Pine.GSO.3.96.970802171922.21995A-100000@james.freenet.hamilton.on.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
[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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0wumRi-0000B3-00>