Ned Konz wrote:

>On Tuesday 29 July 2003 04:45 am, Daniel Vainsencher wrote:
>  
>
>>About using multiple files in a SAR - I don't think it should
>>become an ad hoc replacement for package dependencies. If the
>>packages aren't distributed separately, that means any update to
>>any package's code might require multiple repackaging operations.
>>    
>>
>
>But sometimes a package comes in logical pieces that shouldn't be 
>distributed separately.
>
>  
>
>>However, it could give us a packaging solution to the "patch"
>>problem I mentioned in another thread. That is, I could distribute
>>Garden.sar, which would include garden.mcv and also
>>garden_patches.st
>>    
>>
>
>I'm distributing StarBrowser and SARBuilder like this:
>
>I have the base package(s) in the SAR. Also, I have the extensions a 
>separate members in the SAR.
>
>The extensions are loaded based on their appropriateness: for 
>instance, the SARBuilderMC package isn't loaded if you don't have 
>Monticello loaded.
>
>The one problem with this is that if you later load Monticello you 
>have to go back and load the SAR again to get the SARBuilderMC.
>
>But these packages are not going to be maintained or released 
>separately. They're all pieces of the same package.
>

I handle the same problem in a slightly different way...the problem is 
with loading KomServices and a StarBrowser UI for KomServices.  I use 
two separate SARs, and in the KomServices package I specify the UI 
package as an optional package for loading.  Upon loading, the tool sees 
the optional package an prompts the user if they want to load it (and 
the StarBrowser will get loaded if it is not already).  All of this is 
handled automatically by the KomPackageBuilder tools by simply 
specifying pre-requisite packages and optional packages.

- Stephen