From owner-freebsd-current Sun Aug 3 10:50:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA04785 for current-outgoing; Sun, 3 Aug 1997 10:50:10 -0700 (PDT) Received: from hwcn.org (main.hwcn.org [199.212.94.65]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA04780 for ; Sun, 3 Aug 1997 10:50:07 -0700 (PDT) Received: from james.freenet.hamilton.on.ca (ac199@james.hwcn.org [199.212.94.66]) by hwcn.org (8.8.6/8.8.6) with ESMTP id NAA09919; Sun, 3 Aug 1997 13:50:41 -0400 (EDT) Received: from localhost (ac199@localhost) by james.freenet.hamilton.on.ca (8.8.6/8.8.6) with SMTP id NAA09448; Sun, 3 Aug 1997 13:50:55 -0400 (EDT) X-Authentication-Warning: james.freenet.hamilton.on.ca: ac199 owned process doing -bs Date: Sun, 3 Aug 1997 13:50:54 -0400 (EDT) From: Tim Vanderhoek X-Sender: ac199@james.freenet.hamilton.on.ca Reply-To: hoek@hwcn.org To: Ade Lovett cc: hoek@hwcn.org, current@FreeBSD.ORG Subject: Re: ports-current/packages-current discontinued In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 3 Aug 1997, Ade Lovett wrote: > pkg_add doesn't, no. However, by the addition of another command, > say pkg_register, one could grab a binary package by whatever means, > and then say "I've downloaded this package, I've put it somewhere, > so if you need it at any future point, I have it already" I suppose the main use in this would be for CD-users who could tell pkg_register to go looking on the CD for the pkg. If you're going to go away from packaging all the dependancies of a meta-package inside its single package, then you need a way for CD users to tell pkg_add to automatically search the CD for packages and dialup users to search ftp.mirror.freebsd.org. A URL could point to the global package location (file://cdrom/packages, ftp://ftp.freebsd.org/packages-2.2.2, etc). This still does nothing for the situation (d/l via Zmodem) that I outlined, but I guess I can live with that. > We already have something like this, with the way in which sysinstall > handles 'src', which gives the option of everything, or bits and pieces. Yes, something "like" this. I'm saying it should be done through the existing ports system. If sysinstall wants to divide everything into a gazillion different compartments, I don't really care. I want to see these compartments done through the ports system because of the greater flexibility it provides. > bin/ > bin-base > bin-perl > bin-tcl > ... > bin-ALL > > No? Yes, but through an extended ports system. :) -- Outnumbered? Maybe. Outspoken? Never! tIM...HOEk