From owner-freebsd-ports@FreeBSD.ORG Fri Jan 9 15:00:05 2004 Return-Path: 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 69E8C16A4CE for ; Fri, 9 Jan 2004 15:00:05 -0800 (PST) Received: from mail.blarg.net (floyd.blarg.net [206.124.128.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FA4343D58 for ; Fri, 9 Jan 2004 14:58:58 -0800 (PST) (envelope-from abowhill@blarg.net) Received: from kosmos.my.net (12-230-212-176.client.attbi.com [12.230.212.176]) by mail.blarg.net (Postfix) with ESMTP id AD481385FB for ; Fri, 9 Jan 2004 14:56:15 -0800 (PST) Received: from kosmos.my.net (localhost [127.0.0.1]) by kosmos.my.net (8.12.10/8.12.10) with ESMTP id i09MuULP093200 for ; Fri, 9 Jan 2004 14:56:30 -0800 (PST) (envelope-from kosmos@kosmos.my.net) Received: (from kosmos@localhost) by kosmos.my.net (8.12.10/8.12.10/Submit) id i09MuTf0093199 for freebsd-ports@freebsd.org; Fri, 9 Jan 2004 14:56:30 -0800 (PST) (envelope-from kosmos) Date: Fri, 9 Jan 2004 14:56:29 -0800 From: Allan Bowhill To: freebsd-ports@freebsd.org Message-ID: <20040109225629.GB91968@kosmos.my.net> Mail-Followup-To: freebsd-ports@freebsd.org References: <20040109191335.GA91968@kosmos.my.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PmA2V3Z32TCmWXqI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-URL: http://www.blarg.net/~abowhill/ Subject: Re: Call for feedback on a Ports-collection change X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2004 23:00:05 -0000 --PmA2V3Z32TCmWXqI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Garance A Drosihn wrote: : :So, what I'm shooting for is a *doable* project, but one :which leaves the ports-tree in a state where it would be :easier to do some follow-up projects that would have much :more obvious benefits than this step will have. Raising the bar one notch at a time is sensible from a production perspective, especially if you have a limited time frame and resources. This change sounds like it does have immediate benefits for the user, if the user interface doesn't change. It would probably have a positive effect on the size of locate database and execution time for find, as well as CVSup execution time. I have no idea what, if anything would change in the packaging utilites, sysinstall, package building scripts, CVS support utils, and SGML/Web/Printed documents. There are also several third-party utilities that interface with the ports tree directly that might be broken. Not many. It also might break some scripts at larger ISPs who build or track ports with their own systems, but these groups are usually equipped to handle changes. They might complain a bit, as big directory changes mean they have to script for two different file and directory structures in their repositories, based on date. This might also be a compelling reason to make all the big changes at once, if it can be done. Too many global changes to historically uniform directories and files creates repository muddle, based on dates of change. Maybe this is not all that important an issue to many *BSD users. I can vaguely recall the last really big global change to ports, when Satoshi (then Ports Manager) consolidated some files and directories to reduce inode usage. One thing I remember was CVSup having problems cleaning up old files and directories. Perhaps I didn't have the delete option set, or the sup datafiles got mangled, I can't recall. I can remember solving it by deleting ports entirely, then re-CVSupping. At the ISP I worked, it did cause automation problems, as we had built our toolset around the older set of directories. We had to do some up-conversion of custom ports we offered, and were forced to upgrade and re-evaluate new=20 versions of ports that we offered as-is. Not the end of the world by any stretch, but it cost programming hours to rectify. What I'm saying is that the impact at tier-1 service providers is not insignificant, especially those who offer jailed environments with ports trees for their customers. If you can afford to, I think it might be worthwhile to publish a short document describing the anticipated design, benefits, and impact of your idea. Then nobody can complain changes were dropped on them by surprise. --=20 Allan Bowhill abowhill@blarg.net Chef, n.: Any cook who swears in French. --PmA2V3Z32TCmWXqI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE//zGcBC/kSIeFE54RAl6YAJ9FZXgPSjTLnHA9o/4XMLoExrpfAwCeMxOT PfWH/JDGD+vi8KGW0Q6NTrY= =ypRe -----END PGP SIGNATURE----- --PmA2V3Z32TCmWXqI--