incubator-bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konstantin Boudnik (JIRA)" <>
Subject [jira] [Commented] (BIGTOP-720) Build environment automation
Date Fri, 28 Sep 2012 05:41:07 GMT


Konstantin Boudnik commented on BIGTOP-720:

Thanks for putting this all together!
> Build environment automation
> ----------------------------
>                 Key: BIGTOP-720
>                 URL:
>             Project: Bigtop
>          Issue Type: Task
>          Components: General
>            Reporter: Anatoli Fomenko
>            Assignee: Anatoli Fomenko
>             Fix For: 0.5.0
> Summary of the bigtop-dev discussion:
> A few approaches have been suggested:
> # (Roman) maintain a parallel (very shallow) collection of puppet code that would, essentially,
manage our "build slaves"
> # (Roman) do #1 but automate it in such a way that the info actually gets harvested from
spec/conrol files. (Cos suggested to use Groovy for implementation)
> # (Bruno) VMs.
> There are some pros and cons for each of them.
> For example:
> #3 Pros: 
> (Bruno) Tools like Boxgrinder and Oz can deal with multiple OSes and can create local
images as well as push them to the cloud. The build would be repeatable and would not require
any effort from the end user (apart maybe providing Oracle JDK, but that would have to be
the case whatever the solution). Future contributors would just need to boot their VM to get
started and hopefully ease contribution.
> (Roman) I'd love if I could say
> {code}
> $ vagrant add box/up
> {code}
> and get the environment up and running without much fuzz.
> #3 Cons:
> (Cos) I think boxed environments (like VMs) are an overkill... old proven toolchain type
of environment that can automatically bootstrap upon a fresh install (or update itself: think
Maven model) and pull whatever apps are required in whatever form they might exist... Such
approach would be more fluid than a somewhat rigid VMs, that would have to be updated periodically,
versioned, etc. Another benefit of a toolchain is that BigTop packages might have to redistribute/wrap
some of the tools for later use once a package is installed on a customer's system.
> There are some tools based on SRPMs that can extract a dependency list.
> Roman suggested a simpler approach of grepping and using sed/awk: 
> {code}
> $ git grep -E 'Build(Requires|-Depends):'
> {code}
> Sean was ... in favor of the idea of extracting dependencies from the control and spec
files and building a script that will install the necessary tool chain. 
> Cos mentioned ... It should work, except for build-time dependencies which aren't declared
in the bigtop packages (e.g. libtool, etc.). So, I'd vote for a separated list of build-time
dependencies being maintained.
> Roman separated 3 distinct use cases:
> # provisioning/maintaining a long running Jenkins slave
> # provisioning a host dev environment
> # provisioning a VM dev environment
> Roman also suggested ... a 'virtual' package called build so that running:
> {code}
> $ make build-[rpm|deb]
> {code}
> will create a package that would download all the bits and pieced of a tool-chain AND
also promote BuildRequires: to its own Requires: so that installing this package will give
you all the toolchain bits and all the package deps at the same time.
> The consensus seems to be that all approaches are valid for some use cases, so implementation
may start from simpler approaches, and evolve as necessary.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message