Date: Sat, 12 Feb 2000 18:39:42 -0600 From: Richard Wackerbarth <rkw@dataplex.net> To: Jeremy Lea <reg@FreeBSD.ORG> Cc: freebsd-ports@FreeBSD.ORG Subject: Re: /usr/ports/ too big? Message-ID: <00021220115000.02429@nomad.dataplex.net> In-Reply-To: <20000212161556.D51878@shale.csir.co.za> References: <20000209215806.M99353@abc.123.org> <00021215021001.02300@localhost.localdomain> <20000212161556.D51878@shale.csir.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 12 Feb 2000, Jeremy Lea wrote: > Hi, > > On Sat, Feb 12, 2000 at 02:38:01PM -0600, Richard Wackerbarth wrote: > > I would suggest that we replace each port with a single FILE which contains a > > description and the designator of the port. > > > > The makefiles and patches, etc. for a particular port can then be kept in an > > 'ar'chive which gets expanded only while building. These archives don't even > > need to be fetched until someone wants to build the port. > > How well does CVS handle ar files? ie, is a one line change a one line > diff... Yes, they easily store that way. CVSup can update the line in the file within the archive on an incremental basis just as it does now. > Remember, people need to maintain these, and we do that through > CVS. We *really* do not want to move away from a central port's > repository. I'm not advocating ANY change to the basic structure that the maintainers see. Well, we might prefer to simplify the structure a little; but that is an orthogonal issue. With the scheme I am advocating, it doesn't matter. The fundamental concept is to "wrap up" all of the details of patching and building a "contributed" source tree and distribute them in one file. There are two ways to approach this. A) Have the maintainer "wrap up" the changes and submit it. [He runs the packaging script before submitting to the archive] B) "Hide" the real repository and just distribute the derived files. [Much like you can receive "digests" of a mailing list rather than the individual messages] After receiving the archive, the user unpacks it and has a tree which is the same as the one the maintainer used. I prefer this latter approach because we can play some games in the distribution process. In particular, there is not much reason to distribute any but the most current, or at least recent version of a port. The primary advantage to the cvsupd distributor is that it can be very efficient if has some history and can match the version you already have. The more out-of-date the user's version, the less efficient it is likely to be. At some point, you might as well "send the whole thing" anyway. Therefore, we can save time and space in the distribution system by purging the older history from the distribution system. Since we are maintaining a master repository, it has not lost anything and since we don't really need to actually hide it, it is available for those cases where the older history is needed. This is analogous to the practice of the local library. I can walk into any branch and find not only the current issue of a periodical, but perhaps the last year. However, if I want older issues, I must go to, or have ordered from, the main archive. So the system may have 50 copies of the recent issues, but only two of the old ones. I think we can apply the same logic to file distribution. Those few times someone needs to reach far back into the past, they can either consult their own archives or go back to the master. But the bulk of us are not burdened with "shelves of musty, never referenced, volumes" - - - - For space/time considerations, I advocate delayed distribution of the build details. Thus, I would represent the port as three distribution files 1) A placeholder/description that everyone (who has that port category) uses to browse the catalog of available ports and initiate the fetching of the components to build it. 2) The archive of patches and other build files [the part FreeBSD maintains] 3) The tarball from the original author > Personally, I like the idea of moving to a flat port 'delta'. Although > I'd go two steps further, and make COMMENT the first line of DESCR and > only have a single patch per port. I'd keep the multiple patch files. I think it is easier for the maintainer. It really costs us very little in the build process and when they are all delivered in one archive, they don't have to be handled individually. At the same time, I'd drop the hierarchy in the build directory and, rather than building in the "catalog" tree, use a flat directory with one directory per port. The only problem I see with that is that it might complicate the "package" builder if it doesn't clean things out as it goes along. -- Richard Wackerbarth rkw@Dataplex.NET 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?00021220115000.02429>