There is also the matter of insuring to the best of the project's ability that the binary bits fit together. We do this in the package builds by specifying dependency versions on the Maven command lines used to build. Whether the end result is a bunch of jars in a directory, a bunch of tarballs, or a bunch of deb or rpm archives, most of the effort we have is not maintaining the packaging - it is figuring out a BOM and set of transitive dependencies that can be compiled together and successfully deployed.
Let me turn this question around and ask how difficult it is to do the packaging part _after_ getting the builds of a BOM to all work? I've found it to be 30% of the work, substantial, but not double the effort. That said, it could make sense to not worry about building OS specific packages. The output of a Bigtop build would then be something like a directory full of tarballs that can be unpacked in different locations and combinations but can be assured to work together. Like Cloudera's Parcels I suppose. I also think the current renewed interest in containers is strong, and not a fad, but this is a pendulum that swings around. On Tue, Feb 10, 2015 at 8:44 AM, jay vyas <[email protected]> wrote: > Hi bigtop. Just a thought... (Thanks @rnowling for providing a seed for > this discussion this morning) > > > In BigTop 1x (the experimental branch) we have a chance to do things > radically different. > > - How long are we planning on actually running bigtop on multitenant > systems Months or years? > - I we move towards individual processes/microservices/containers, who > will be consuming our RPM/DEB packages ? > > ...If nobody... then bigtop 1x could purely focus on nothing other than > - integration testing, > - cutting edge deployment, and > - puppet recipes > > without worrying at all about packaging details. There are tools for DNS > for containers and so on. > > > -- > jay vyas > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
