[Bro-Dev] Tarballs

[Jonathan Siwek]

> > I think maybe the broctl source package wouldn't need to include
> > broccoli since that's got it's own?
> 
> Yeah, sounds right.

Alright.  I think CMake/CPack can be made to behave and produce this package structure.

> > I'd rather just download a single RPM, DEB, OS X installer, etc, that has
> > everything I should ever need.
> 
> Same here, but I think the arguments above apply here as well: would
> be nice to be able to update broctl separately, and to install
> broccoli indepedently of anything else.

Sounds good; I'll agree that the binary packages can mimic the source ones.

Want to decide what formats of binary packages to provide?

I think I can claim that DEB, RPM, Mac PackageMaker, and tarball formats are possible by relying on CPack, but it looks a little ugly...

For generating RPMs, it's difficult to get full control of package metadata (description, license, maintainer name/email), so the package might not look so professional.

For generating DEBs, the package dependencies will not be set automatically, so CPack is basically unusable.  As a workaround, "alien" can be used to generate a DEB from RPM w/ correct dependencies, but again it's difficult to get control of metadata.

For Mac PackageMaker or tarball formats, one deficiency I remember is that you can't unpack to just any directory and have bro work because the default policy search dirs are set at compile time.  Also, with tarballs we'd probably have to link all the dependencies statically; with PackageMaker, vanilla OS X comes with all required dependencies and I think it's sufficient to just ship the optional ones with the package.

Given that description, how comfortable are you with relying on CPack to make RPMs (converted to DEBs via alien) and Mac PackageMaker binary packages?