Date: Fri, 08 Jun 2001 11:48:56 +0300 From: Maxim Sobolev <sobomax@FreeBSD.org> To: Doug Barton <DougB@DougBarton.net> Cc: will@physics.purdue.edu, portmgr@FreeBSD.org, ports@FreeBSD.org Subject: Re: pkg-comment && pkg-descr && distinfo Message-ID: <3B209177.5D729F28@FreeBSD.org> References: <200106072015.f57KFLo22248@mail.uic-in.net> <3B2078DA.BD47A1C8@DougBarton.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Doug Barton wrote: > Maxim Sobolev wrote: > > > > On Thu, 07 Jun 2001 11:06:31 -0700, Doug Barton wrote: > > > Will Andrews wrote: > > > > > > > > So Doug, > > > > > > > > Are you going to take my offer? > > > > > > Yeah, sorry, I forgot to respond to your e-mail. I'm hoping to work this > > > up on the weekend. > > > > > > Do the script to automagically > > > > calculate all MD5 checksums and put it in the Makefile > > > > flawlessly (probably needs a manual override, of course), and > > > > I will do all the patchwork (some will be involved) and Makefile > > > > updates in the ENTIRE ports tree to adjust for the changes. > > > > > > > > I'm serious. > > > > Hey folks, please hold on. There was absolutely no discussion > > about moving distinfo into makefiles > > Actually there was quite a bit of discussion about it, as you referenced > in your second e-mail. :) > > > and frankly speaking I do > > not see much point in doing that. Yes, this will save some amount > > of inodes, but it is hardly a good argument. > > It'll also cut the disk usage in half for the average Makefile + pkg-descr > + pkg-comment + distinfo combination. Currently those 4 files use 4 inodes > and 4 frags. Combining them all into the Makefile uses 1 inode and 2 frags. > When you spread that over thousands of ports the performance benefits for > the average user far outweigh the diskspace/inode savings, which I agree > are semi-trival in today's hardware world. > > > For example that would > > break many port-related tools out there > > So they adapt, just like they did to the most recent changes. In fact, if > you'd just have used my plan in the first place we wouldn't be having this > discussion, the pain would already be over with. :) > > > and could make some > > things harder in the future. For example people could start using > > make(1) variables in the various parts of distinfo, > > OH NO! That might make the ports system more flexible and easier to expand > to the needs of the users!! IT MUST BE STOPPED. > > > so you will be > > unable to parse distinfo w/o using make(1), which will make it a > > *very* expensive operation, so things like distclean will take > > forever to complete. > > So rewrite it as a makefile (that's distclean.sh, which you clarified). > The argument that "we can't do that because we'd have to change things" > doesn't fly with me. If something is the right thing to do on technical > merits then you make the tools fit the science. If you can argue > convincingly that cutting resource usage by 75% is bad, or that the current > system will scale another order of magnitude, knock yourself out. But > please don't use inertia as an excuse when there are people willing to make > the new system work. > > > Please start discussion by providing your arguments explaining why > > we should move into that direction, not from the technical possibility > > of the move itself. > > See above. I posted hard numbers to the thread on -ports as well. One of > the biggest complaints about the ports is how long they take to unpack, and > how wasteful of resources they are. This becomes geometrically more > problematic as the ports collection grows. In addition to the on-disk > resources, this would be a huge win for the ports repo, and ripple all the > way down to every user on every cvs[up] update of their tree. Personally I > can't see any justification for leaving 4 files in place where 1 would do > the trick. Yes, some things will have to change, but that's part of the > evolutionary process. > > Please note that no part of this argument implies that there is something > bad or evil about the current ports system, or the people who've worked > very hard to get it where it is today. My only point is that it's already > past the point efficiency, and getting "worse" with every port added. Here > is a simple thing that can be changed to help this problem tremendously. > > > If my memory serves, either peter or jdp told that such > > saving isn't really important, and as long as they are our > > cvs meisters we could trust their opinion. > > John mentioned that combining pkg-comment and pkg-descr would only save a > trivial amount of disk space (< 5M) in a checked out tree. TMK no one has > done a benchmark on the cvs costs, but think about it. A "typical" port has > 8 files. Makefile, distinfo, pkg-* and a few patches. My proposal cuts that > down to 5 files. Personally I think that reducing the number of files > compared by ~38% would be a good thing. :) Not to mention, a significant > portion of ports updates change only the Makefile and distinfo. Combining > them means that at update time half the number of files actually need to > get synched, which reduces the overhead quite a bit. Synching two bits in > one file is easier than synching two bits in two files. You are missing one big point, that makes your arguments very poor. It is the fact that Makefiles aren't really intended to be used like that. Text description is functionally different from the "engine" provided by makefile, so merging it into one file would be an ugly hack that would obscure the things beyong the reasonable point. It is similar if someone would argue that there should be only one source file for each utility in our src/ tree, or even that source files and manpages are to be merged with Makefiles to save large number of inodes. If someone can't bear ports tree and want to save inodes that he/she should really use packages instead. Perhaps at some of the future, when we will move away from Makefiles (to xml or anything else) this issue could be reconsidered, but now it is not sounds reasonably for me. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B209177.5D729F28>