[jira] [Commented] (BIGTOP-720) Build environment automation

["Konstantin Boudnik (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/BIGTOP-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13465381#comment-13465381 ] 

Konstantin Boudnik commented on BIGTOP-720:
-------------------------------------------

Thanks for putting this all together!
                
> Build environment automation
> ----------------------------
>
>                 Key: BIGTOP-720
>                 URL: https://issues.apache.org/jira/browse/BIGTOP-720
>             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: http://www.atlassian.com/software/jira