Date: Sun, 13 Feb 2000 21:31:14 -0600 From: Richard Wackerbarth <rkw@dataplex.net> To: Chuck Robey <chuckr@picnic.mat.net> Cc: ports@freebsd.org Subject: Re: /usr/ports/ too big? Message-ID: <00021322201205.06543@nomad.dataplex.net> In-Reply-To: <Pine.BSF.4.21.0002132219090.23833-100000@picnic.mat.net> References: <Pine.BSF.4.21.0002132219090.23833-100000@picnic.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00021322201205.06543>