jsiwek at ncsa.illinois.edu
Mon Nov 29 08:49:28 PST 2010
> Here's a proposal for tar-balls to offer for download in the future,
I think maybe the broctl source package wouldn't need to include broccoli since that's got it's own?
What you outlined seems to make the most sense to me in the cases where broccoli or broctl come out with new releases that are yet included in a bro release -- then a user could try to upgrade those modules (hopefully) without affecting bro.
Do you anticipate broccoli & broctl frequently having releases not in sync w/ bro? If not, I'm thinking it's easier to just have a bro-all and a bro-scripts source tarballs.
Was there other benefits associated with having those extra source tarballs (broccoli, broctl) that you had in mind?
> We could do our binary packages along a similar structure.
>  Distributions will want it separeately per repo, but for, e.g.,
> an MacOS package, it seems more convinient to have few pieces to
Yeah, I think distributions will likely put finer grained packages in their repositories, but personally, if I were downloading a prebuilt package from the website, I'd rather just download a single RPM, DEB, OS X installer, etc, that has everything I should ever need.
More information about the bro-dev