On Tuesday 25 September 2007 09:51:57 am mcb, inc. wrote: > Hmmm, list has been silent on this question. Well, I have > another. The same package also has an optional java-based > component. Would the election to include this part be best > handled with flavors? And if so, should the flavor pull in > a default java system if one isn't found or should it fail > loudly early in the build?
Here is some general advise on how to select between a flavor or a multi-package... feature Y == some optional feature that most users don't want or perhaps has heavy additional RUN_DEPENDS (like java), WANTLIB or LIB_DEPENDS. The way to choose between a FLAVOR or a multi-package goes like this: If by adding feature Y some file within the existing PLIST/PFRAG changes then you must use a FLAVOR for feature Y. For example if the program or shared libs optionally compile in new code when feature Y is added then it must be a FLAVOR and stop here. There's an exception to this rule but it requires the porter to look at what changed in the main package to see if the author did something like using dlopen() to handle gracefully the possibility the optional feature is missing. If the porter doesn't know how to make that evaluation then just stop here too. On the other hand, if by adding feature Y you only get additional files added to your PLIST/PFRAG then a multi-package is by far preferred. It is preferred because it makes it easier on the users who install packages. To get feature Y just add the multi-package for it instead of a completely new flavored package. The additional depends associated with feature Y are only placed on the Y multi package so the main package doesn't depend on them. Remember its all about the packages. They are the final product and generally speaking we don't care about heavy BUILD_DEPENDS. It's the RUN_DEPENDS, WANTLIB and LIB_DEPENDS that effect the packages. In many cases if feature Y is for java it falls into multi-packages, but you need to evaluate it for your particular port. -Kurt
