From owner-freebsd-ports@FreeBSD.ORG Thu Jan 8 20:17:54 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 4484216A4CE for ; Thu, 8 Jan 2004 20:17:54 -0800 (PST) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id E366043D2F for ; Thu, 8 Jan 2004 20:17:44 -0800 (PST) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 5F381146FA; Thu, 8 Jan 2004 22:17:44 -0600 (CST) Date: Thu, 8 Jan 2004 22:17:44 -0600 (CST) From: Mark Linimon X-X-Sender: linimon@pancho To: Garance A Drosihn In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-ports@FreeBSD.ORG 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 04:17:54 -0000 > and then fill that directory with files patch.001 through > patch.042. I think this is a step backwards. Let's consider the problem from a maintainence standpoint. The files that change the most rapidly are files/patch-*, because they are affected both by port updates, and also changes to the underlying infrastructure such as the recent gcc3.3 import which we are still struggling with. Giving these things symbolic names helps to keep clear what's doing what. Next most rapid to change are Makefile and distinfo and that's just talking about version tracking. Some external code is released on a quite regular basis. Sometimes this can be dealt with by just a change to portrevision and checksum; sometimes not, and something else needs to change such as portepoch or the install tweaks. The next most rapid to change are plist and those tend to change less often than the distinfo changes, but there are the occasional exceptions (generally chasing down plist bugs found during packaging). The next most rapid is the pkg-descr and that's generally because the URL move around (of course, that affects Makefiles too). The pkg-message and pkg-comment files were the ones that were mostly static. The reason pkg-comment was nuked was that it was only one line. Remember, too, that during the conversion, the ports tree was unstable for a time (having a free-form text line with all kinds of special characters really gave the make infrastructure a bad case of gas), and in addition there was a lot of repo-churn. I'm still not personally convinced it was worth the pain, but that's water under the bridge. I think the same arguments pro and con could be made for incorporating pkg-message. There would be N less files, but N more opportunities to mess up the Makefiles (if that was the way you were going to go about it). And then, there's the repo-churn. Every single consumer of cvsup would wind up having to reload a copy of every single port. That's a lot of bandwidth, too. But in your plan, if I understand it, a change in any of these things results in a change to a single, unified, file. Now I can't go to the CVS logs and quickly say, oh, the last year's worth of Makefile changes were just to keep up with infrastructure changes; the distfile hasn't changed in 2 years. (This is a very common situation). Now, for each change, you have to go through and find out exactly what it applied to. Now let's consider maintainability once again. The ability to separate the patches into discrete files with descriptive names is a very powerful thing if you're someone like me who winds up trying to do updates to a large number of ports. I find the ports with a large number of patches stuck together in patch-aa, patch-ab, etc., to be incredibly frustrating to work with. You can't even tell from glancing at them if they even overlap. I think it would be a mistake to take away the ability to rapidly browse these files. In any case worrying about inode count strikes me as an early- to mid-90s kind of problem. Fry's has 250Gs on the shelf. ISTM that there's room for lots of inodes on that. Honestly, I think if some work was done that would touch every port in the ports system, it ought to be something that gave us so much generalization as a tradeoff for the pain that would ensue (something like some kind of meta- descriptor language?) that it would be worth it. I really can't agree that this is it. To me, I really think you're trying to solve a problem here that just isn't a problem for the majority of users, at least with respect to the amount of repo-churn and bandwidth-churn it would entail. mcl