From owner-freebsd-ports Sun Feb 13 20:22:29 2000 Delivered-To: freebsd-ports@freebsd.org Received: from mail.utexas.edu (wb3-a.mail.utexas.edu [128.83.126.138]) by builder.freebsd.org (Postfix) with SMTP id 8F152495D for ; Sun, 13 Feb 2000 20:22:22 -0800 (PST) Received: (qmail 6325 invoked by uid 0); 14 Feb 2000 04:22:26 -0000 Received: from dial-51-34.ots.utexas.edu (HELO nomad.dataplex.net) (128.83.113.130) by umbs-smtp-3 with SMTP; 14 Feb 2000 04:22:26 -0000 From: Richard Wackerbarth To: Chuck Robey Subject: Re: /usr/ports/ too big? Date: Sun, 13 Feb 2000 21:31:14 -0600 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: In-Reply-To: Cc: ports@freebsd.org MIME-Version: 1.0 Message-Id: <00021322201205.06543@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 13 Feb 2000, you wrote: > On Sun, 13 Feb 2000, Richard Wackerbarth wrote: > Well, the load on cvsup is pretty minimal, Yes, I know how the system works. The load on the cvsup servers I was talking about is the load for them the resync every hour with their master and, more importantly, every client who demands service. Actually, they have it easier in ports than they do in the src tree. Over there requests for the 3.x branch have to pass a lot of the "dead" file. Keeping long lived variants was not an intended use of cvs. It does not handle them well. We would be much better off if we had a separate source tree for each major branch. This would work even better if we added "tree hopping" links to the cvs structure so that we didn't need to replicate the common elements of the older history. > I think, honestly, that while you are right in essence, Richard, you're > proposing something that is too extreme for most of the porters to > accept. HAS ANYONE REALLY READ WHAT I HAVE PROPOSED? 1) Rename the Description of the port to the name of the port and use them to populate a separate description tree. This is the only structural change that I am proposing. In actuality, this could be done in step 5 below if the porters are so inflexible that they cannot accept any change. = = Isn't it somewhat hypicritical that the "users" are expected to "live with" changes imposed by the developers but they are priviledged to stand in the way of someone else's changes == 2) Take the rest "offline" just as we have the distfiles offline. However, in this case, they would all come from the FreeBSD distribution servers rather than from various sites all over the world. 3) (optionally) Flatten each port to a single directory (This is an orthogonal change -- take it or leave it -- with or without the rest) 4) AFTER the port maintainer checks in his changes to the master tree (NO change here), we prepare a derived representation which is in shar format (or similar). 5) These archives are checked into the distribution tree. -- NOTE: Steps 4 and 5 are AUTOMATICALLY performed by the repository just as mail is automatically sent today. 6) Periodically (monthly or semi-annually) purge old history from the distribution archive (only), thus reducing the size of that archive. Note that the history is not lost because it is still in the master repositiory. It is just not in the popular distribution channel. 7) To use a "new port", the user would simply "make setup" in the description tree and cd to the resulting tree which gets fetched (if needed) and expanded. IOW, I have added two "steps" to the build sequence. At the end of them, the porter is right where he started. > This kind of thing, if *really* wanted, is *very amenable to demonstration. Not really. It is too hard to "simulate" non-manual steps involving the master repo. And as far as "customer demand", I don't see how to test market it without doing a large scale rollout. With the track record of these ostriches, I'm not about to put in the effort only to have it vetoed because some primidonna starts pouting. > Unfortunately, none of us wants this idea, it's sort of removing nice > details for programmers to meet a need we don't all believe in. What "nice details"? I don't think any of you have read beyond the (NIH) word "change". -- Richard Wackerbarth rkw@Dataplex.NET To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message