Date: Sun, 10 Nov 1996 10:44:47 -0500 (EST) From: Chuck Robey <chuckr@glue.umd.edu> To: Satoshi Asami <asami@FreeBSD.ORG> Cc: FreeBSD-Ports@FreeBSD.ORG Subject: Re: blt2.1 Message-ID: <Pine.OSF.3.95.961110103315.17739A-100000@fiber.eng.umd.edu> In-Reply-To: <199611101147.DAA01424@baloon.mimi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 10 Nov 1996, Satoshi Asami wrote: > * Understand that itcl doesn't sit beside tcl, it replaces it. > > I have no problem with that. In fact I have no intention to engage in > a debate on what itcl is supposed to/not supposed to do, that's not my > expertise. > > The only concern I have is consistency between packages. Say, if the > BLT port is going to find itcl and link against it if it's found, then > we need to add a dependency for it, or the user might end up with a > package that doesn't work because of missing package dependencies. > > Maybe we are nearing the end of our package scheme, it's just not > capable of handling situations like this. But that's why I'm very > sensitive about ports that want to auto-detect and use every utensil > in the kitchen they can find, because our build machine tends to have > the whole three-story toolshop which the user's machine almost > certainly does not. Yeah, I understand. You have a choice of either limiting the port, or the package. It would be nice to a choice for package users, but I just don't see it being all that practical. My personal choice is to limit the capabilities of the package users, because that at least serves the least common denominator, and I think that those who bother to do their own compiling deserve more functionality. I could, with some trouble, arrange for the configure script to be schizophrenic about things, but the trouble is that during the configure phase of building, you don't normally know that your end target is a package (it's possible to make a package either just after doing an install, or from a cleaned port with no workdir). If there was a way to require generated packages to have their own specially built sources to work from, then I could safely condition the configure scripts. Most people don't build packages, do they? I mean, we could alter the road from cleaned to to delivered package, without inconveniencing most folks, right? If packages could be forced to build from targets that were specially conditioned for packages, then the port builder could enforce conditions on the package, and we could have a written policy on what kind of functionality to be allowed for packages. Comment? ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+-----------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSF.3.95.961110103315.17739A-100000>