Date: Mon, 11 Nov 1996 17:52:09 -0500 (EST) From: Chuck Robey <chuckr@glue.umd.edu> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: Satoshi Asami <asami@freebsd.org>, FreeBSD-Ports@freebsd.org Subject: Re: blt2.1 Message-ID: <Pine.OSF.3.95.961111173740.25536A-100000@maryann.eng.umd.edu> In-Reply-To: <2481.847720359@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 11 Nov 1996, Jordan K. Hubbard wrote: > > I see, we're taking orthogonal directions. Mine would have a different > > package for each set of options, yours would build every possible option. > > I think it's an important distinction. Let's say (as a very > reasonable example) you wanted to make the emacs package dual-use for > those with and without X, e.g. provide an emacs binary which doesn't > fall over in the absence of X libraries if the user chooses the > "NO_X11" version. In your scheme, you'd need to build two completely > different emacs packages with replicated lisp libraries, info, the > whole whack. Mine would have two flavors, the only files being > replicated for each flavor (instead of being hashed to the same entry) > being the actual emacs executables which differed. > > > OK, if you want that direction. Do you include any hackery to allow the > > guy who builds his own ports just to build and install the parts he wants? > > That's a ports issue, not a packaging issue. :-) The port can still be > as clever as it wants and not affect any of my stuff, and it's only > the "package" target I see changing to any degree in bsd.port.mk. I don't want to drag this out interminably, but there is a problem that is not covered in your suggested approach. Most ports that build in more than one flavor, like the vim/gvim port that I used earlier as an example, don't build all the different versions. This is often because the phases right at the start, patching and (most importantly) configuring, often causes the build process to be very different. These build processes are not totally compatible, and making them compatible would (in many cases) be a large amount of work. Building them seperately would be relatively simple, since that is how the software was orignally designed, usually. Your appraoch assumes that all ports are going to be redesigned so that every possible version is built, which is not a really pleasing approach to take (it really bloats the required build area, lengthens the build time, requires major changes to nearly all software that has more than one flavor to build [to force parallel builds] and contributes absolutely nothing to the person that compiles their own ports). If this parallel approach is not taken, then you have no way to force uniformity of packages; some would be complete, and some not. It would end up depending on who made the package up. One final argument: this increases the size of packages in a major way. Counter these arguments, and I promise not to raise any more of them (I'm not really into religious wars). I think I've got answers to all of them in the paradigm of making packages depend on options, the only down side to that is a much greater multiplicity of packages needed for ports that have multiple options. OTOH, I know little about the package side, and my proposal needs no changes in the package tools. This probably makes me less able to see your arguments, coming from a premise of changes in the package tools being the way to go. ----------------------------+----------------------------------------------- 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 picnic, both FreeBSD (301) 220-2114 | version 3.0 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.961111173740.25536A-100000>