On 09/24/2012 10:14 PM, Konstantin Boudnik wrote:
On Mon, Sep 24, 2012 at 10:07PM, Roman Shaposhnik wrote:
On Sun, Sep 23, 2012 at 3:41 PM, Bruno MahИ <[email protected]> wrote:
Regarding the size, it depends on a lot of things (using raw vs qcow, how
many packages installed...).
For instance the Apache Bigtop VMs take quite some space because they
reserve some free space so people can upload their datasets. But for a build
VM, not that much space is needed.
For reference, we could put Apache Bigtop distribution on a bootable USB key
:)
------------------------------------------------------------------------------------------------
tl;dr; here's what I propose a 'virtual' package that would
enable the following workflow:
$ make build-[rpm|deb]
$ sudo [apt-get|yum|zypper] install output/build/build*.[rpm|deb]
and you get EVERYTHING that is needed for bigtop builds
installed as packages plus you get /opt/bigtop-toolchain
bits.
-------------------------------------------------------------------------------------------------
Ok, I can certainly see a reason to maintain VMs. Personally, I'd love
if I could say
$ vagrant add box/up
and get the environment up and running without much fuzz.
That said -- this is but a single use case. So lets enumerate
the ones I see:
1. provisioning/maintaining a long running Jenkins slave
2. provisioning a host dev environment
3. provisioning a VM dev environment
I specifically split #3 from #1,2 because a lot of time you can't
(already running in a virtualized environment) or won't (personally
I do a LOT of development on my host OS) go the VM route.
Thus, however appealing VMs are I think we can't escape
the simple truth that we have to have a non-VM based solution
for at lest #1 and #2.
How about if we simple add a 'virtual' package called build
so that running:
$ make build-[rpm|deb]
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.
I think I can prototype it in a couple of hours unless there's
a strong revulsion towards this type of solution (and even
then I think I might just do it for my own personal
gratification ;-)).
I think having a package like this doesn't contradict to the VM need. Even
more - it dovetails into the concept very nicely, because with such a package
in place the VM creation would be completely separated from the essence of the
toolchain and would be simply a breeze.
If you are looking for a blessing - you have mine for sure ;)
Cos
Oh sure. It was never an either/or choice.
Code speaks louder than debates so you have my blessing as well.
