From owner-freebsd-ports@FreeBSD.ORG Thu Jan 8 21:08:00 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 D922C16A4CE for ; Thu, 8 Jan 2004 21:08:00 -0800 (PST) Received: from smtp1.server.rpi.edu (smtp1.server.rpi.edu [128.113.2.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADD9743D46 for ; Thu, 8 Jan 2004 21:07:58 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp1.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i0957tLJ027359; Fri, 9 Jan 2004 00:07:55 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Fri, 9 Jan 2004 00:07:53 -0500 To: Mark Linimon From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) 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 05:08:01 -0000 At 10:17 PM -0600 1/8/04, Mark Linimon wrote: >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). It could very well be that some of the files should *NOT* be collapsed into this new file, for reasons like you describe above. That's certainly the kind of insight that I do not have a good-enough feel for. >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. Inside the proposed pkg-data file, the patches can have whatever names you want. (That was already part of my plan). For instance, you could name each patch for the exact filename it modifies (if you wanted to) -- including directory names and using '/'s as separators. It's just that when the program spits them out, it'll do it into boring-named files. That was my thought, at least, I'm certainly willing to spit them out with other names. >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. That's a lot of DISK SPACE, but no matter how large the disk is, it is unwieldy to have files which are 100 bytes per inode, instead of (maybe) 2000 bytes per inode. When I'm talking about larger disks, I'm thinking that as the size of the disk increases, the more you're going to have larger values for f_bsize or f_frsize (in statfvs). You don't want a 200gig disk with a 256 byte block-size. And if you have a 8192-byte block size, then you're wasting disk space on almost every file in the ports-tree. Not only that, but you're killing performance when doing operations on the entire ports tree (an operation such as 'cvsup'). The amount of time to find-and-read ten small files is going to be much more than to find-and-read one larger file (particularly if that entire larger file can still fit in a single block on the disk). >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. Let me just say that I have some long-term ideas which are a bit more ambitious, but this idea is a doable first-step towards those ideas. I don't really think *I* can do the longer-term ideas, but I can leave the ports-tree in a more flexible state for other projects to take advantage of. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu