From owner-freebsd-ports@FreeBSD.ORG Thu Jan 8 22:46:41 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 C84EA16A4CE for ; Thu, 8 Jan 2004 22:46:41 -0800 (PST) Received: from web21505.mail.yahoo.com (web21505.mail.yahoo.com [66.163.169.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 3D6E643D31 for ; Thu, 8 Jan 2004 22:46:39 -0800 (PST) (envelope-from william_devries2000@yahoo.com) Message-ID: <20040109064639.70858.qmail@web21505.mail.yahoo.com> Received: from [12.229.101.2] by web21505.mail.yahoo.com via HTTP; Thu, 08 Jan 2004 22:46:39 PST Date: Thu, 8 Jan 2004 22:46:39 -0800 (PST) From: William DeVries To: Garance A Drosihn , Mark Linimon In-Reply-To: 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 Reply-To: william_devries@wsu.edu List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2004 06:46:41 -0000 --- Garance A Drosihn wrote: > 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. The pkg* files in this directory, and the packing list(p-list) are copied in the package manager's database directory for the port, so the way it's set up now is logical, except for the remove of pkg_comment file. This some of these file are modified in some rules, like the p-list, so in your > > >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. What do you mean by "spit them out." If you mean extract the files then the changes needed to do this would probably be fairly trivial(I haven't read the whole file). As I understand this stuff, you could use tar to bundle up the files, then add an a new rule to bsd.port.mk to extract the files. Then in the default rule, the one that gets called when you type 'make,' you could call your special rule. To maintain compatibility with current ports, this new rule should not crash and burn if one of your new files is not present, thus allowing the use of the old system. I not going to pretend to know if this is suggestion is actually correct. If you plan on storing them in variables in make, then it would be much more complicated. For the pkg* and p-list files the changes to bsd.port.mk would be fairly easy, but the patches would be somewhat complicated. It sounds like(from other post) you mean the first. > > >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. I would imagine that most people don't care about a few megabytes of disk space. A clean understandable design is probably more important, not that we have that now. > > 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). The time that the port system spends reading and writing to these files is probably very small, and thus not important. "Premature optimization is the root of all evil" - D. Knuth I don't understand how > > >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. I don't think what you are suggesting is needed, but there are many things that could probably be done here that would be very useful, like documenting of all the rules in bsd.port.mk. What are the other ideas, just because one idea is not liked, does not mean the other will be. If I got something wrong, forgive me. --William DeVries > > -- > Garance Alistair Drosehn = > gad@gilead.netel.rpi.edu > Senior Systems Programmer or > gad@freebsd.org > Rensselaer Polytechnic Institute or > drosih@rpi.edu > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus