Date: Wed, 19 Jun 1996 12:53:42 +0100 From: Paul Richards <p.richards@elsevier.co.uk> To: Poul-Henning Kamp <phk@FreeBSD.ORG> Cc: current@FreeBSD.ORG Subject: tcl -- what's going on here. Message-ID: <199606191153.MAA07207@cadair.elsevier.co.uk> In-Reply-To: <480.835157755@critter.tfs.com> References: <199606190353.NAA28433@genesis.atrad.adelaide.edu.au> <480.835157755@critter.tfs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> "Poul-Henning" == Poul-Henning Kamp <phk@FreeBSD.ORG> writes: Poul-Henning> No I don't think it is optimal to import the uuencoded Poul-Henning> tarball, but it sure as hell beats importing the tree. This really sucks big time. Poul-Henning> Why ? Poul-Henning> 1. People will have to make their changes as patches Poul-Henning> this way. So our src tree now consists of uuendoced third party packages and a set of patch files, wonderful, real progress! Poul-Henning> 2. It makes communication with the author(s) easier that Poul-Henning> we know what our changes actually are. cvs will allow you to do this perfectly well. Some of the recent arguments against cvs are valid but there really isn't any good reason why vendor branches can't be used correctly for this sort of thing. In fact, patches make this whole thing harder not easier, at least with cvs *some* of the merging will get done automatically, with patches you have to throw away the old set and start again on the new release. More garbage in the attic and more work to do updates. Poul-Henning> 3. It makes it easier for people to experiment with a Poul-Henning> never version on their own. How is that exactly? Seems like simply compiling the new release is about as easy a way as you can get to try out new versions. Poul-Henning> 4. It takes up LESS space. I'm going to have lots of uuencoded files in my attic in six months time and I really don't want that sort of crap lying around. Can ctm deal with diffs to uuencoded files or am I going to get 2Mb mail messages every time something changes in tcl? No-one ever considers the size of the cvs repository or the hassle modem users have staying in sync. Poul-Henning> 5. It makes Makefiles easier to make. Not true, writing a Makefile for BSD is *really* simple, what you really mean is it avoids the hassle of trying to bmake tcl. Poul-Henning> The discussion ? well, I have tried to start it several Poul-Henning> times, and nobody seemed to care, so they obviously Poul-Henning> cannot feel too much about it ? Well I've never seen anything on this issue. Where did it take place? Poul-Henning> I would prefer if we put the files in $CVSROOT/foobar Poul-Henning> for some value of foobar and made a sup-target for them. Poul-Henning> They could live there as bare binaries, not uuencoded, Poul-Henning> if CVS would not get confused about it. What the hell are you trying to achieve? Why would I want bare binaries in my cvs repository? This strikes me as a lazy solution to the problem. We *used* to have a rule that anything that was critical to the base OS had to be bmaked before it went into the base tree. Seems like this is now out the window because a couple of core members want a new toy and don't want the hassle of maintaining it. bmaking things is quite tricky, I did quite a lot of them when we started out (including the first few versions of gcc 2 we used) so I do know what's involved but it's worth the effort because it keeps *our* tree clean and smaller since the stuff not needed isn't brought into our tree. If something is going to use the ports mechanism why can't it just stay in ports? One of the big pluses I've heard from users when comparing, say, FreeBSD to Linux, it the unified build environment. You're now smashing that to pieces. This screws up all sorts of stuff. I can't have my src tree write only and use obj directories anymore. I can twiddle the WRKSRC variable I guess but then my ports would build in the same place as the base OS then. You're screwed if you want to have a priviliged user maintain you system sources but allow users to build ports. The global build variables will not apply to these encapsulateed products, such as NOPROFILE. I think the whole idea of using the ports mechanism to build parts of the main tree *REALLY* stinks big time. If you're not willing to take on the maintenance of these things then leave them out of the tree, don't bring in even more stuff to increase the maintenance load. All you've done is moved the sources from the ports area into the main source tree for no good reason whatsoever. If you have tools that you'd like to see as part of the main tree that require tcl then there are other ways to do it, such as simply making them check for the existence of tcl and only installing them if it exists, then people can decide whether they want the tcl tools or not. If these new tools are going to be such an integral part of the system then commit yourselves to supporting tcl as part of the base OS and bmake the thing. This is all really nasty, there's no compelling reason for tcl to be brought into the main tree, just because Jordan and Poul like it and have some new toys that could just as easily have stayed in ports. Unfortunately, it's a fact of life in FreeBSD these days that certain people in core consider FreeBSD to be theirs and don't see any need to discuss issues with the project as a whole or even other core members because it just gets in their way. This whole tcl idea is just plain wrong and I really hope that Peter and Joerg can get them to see sense.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606191153.MAA07207>