[Users] OS-independent ovirt-engine distribution archive
Hello, I'm very slowly working to make ovirt-engine running on a BSD system. My problem is that I do it for fun and as my time resources are not big I could not choose building ovirt-engine from sources as it would push me to "port" (make packages) for all java dependencies. Yes, during build maven cannot download Internet and build dependencies (for security reasons). Would be possible to have (another) distribution archive of ovirt-engine which would be OS/distro-independent, so I could just extract and copy it to filesystem for local jboss? (RPM packages can be extracted with 'rpm2cpio' but their owners decided to make life very complicated [many symlinks etc.]). OS/distro-independent distribution archive (.zip, .tgz) would make life much easiers for people wanting to have ovirt-engine running on a non-RPM based Linux distro or on a BSD/Solaris system. jbelka
----- Original Message -----
So I guess you can download rpms from the internet and not maven artifacts... What is the difference between the two? Building using maven will prepare a full distribution exactly as you need, you just need to build it in a computer that is connected to the internet and then wrap up the resources and transfer it into the internal network. Execute: $ make $ make install DESTDIR=/tmp/ovirt-engine-root Regardless, porting the application to different distribution requires more work as the startup service and setup environment are somewhat redhat/fedora specific. Of course help will be appreciate, we are planning to solve the setup issue by rewriting it to match otopi infrastructure it will be one step closer to be able to customize it to different distributions. Alon
On Tue, 8 Jan 2013 04:03:58 -0500 (EST) Alon Bar-Lev <alonbl@redhat.com> wrote:
So I guess you can download rpms from the internet and not maven artifacts...
That's what I'm doing right now...
This is what I would like but it should be done by ovirt team itself. BSD port systems (are generally just Makefiles) can _only_ download official archives and build them "locally".
That would be nice. jbelka
----- Original Message -----
When using maven the whole concept of "official" archive is different. BSD ports build from source, so it should download sources, and sources do not include any of the external dependency nor binaries. Am I right so far? The problem with maven is that it downloads dependencies during source build, which is invalid approach as far as build methodology is concerned... but it is what it is. The Fedora project added wrapper to force maven to use local repository and for maven artifacts to be installed at this local repository. This is healthy solution as you build dependencies as standard packages, then maven will fetch and use these local packages. What you seek is binary distribution so ports will use binaries, is that matches *BSD policy?
On Tue, 8 Jan 2013 04:24:11 -0500 (EST) Alon Bar-Lev <alonbl@redhat.com> wrote:
Right, or more exactly... Building a source via ports mechanism forbids that the build process to download any of the external dependency or binaries.
Yes.
This is best way but I'm not able to maintain these build dependencies.
What you seek is binary distribution so ports will use binaries, is that matches *BSD policy?
Using just binaries is fine for ports mechanism, for example tomcat on OpenBSD uses binaries, my WIP jboss port uses official binaries too. jirib
it is now available via ovirt nightly builds as 'ovirt-engine-archive.tar.gz': http://resources.ovirt.org/releases/nightly/src/ Eyal. ----- Original Message -----
On Wed, 27 Feb 2013 06:41:07 -0500 (EST) Eyal Edri <eedri@redhat.com> wrote:
Thank you very much! But.. can I respectfully ask archive tarball having date/version in its filename (ovirt-engine-archive-20130228.tar.gz)? I suppose ports (makefiles to build a BSD package) with source files without unique date/version in filenames would never be accepted. Right now I'm quite busy, I've just made some tunning of path to python interpreter, replaces absolute symlinks with relative... Real modification for BSD system (here OpenBSD) is on my TODO. I suppose hard stuff would be modification of engine-upgrade :D jbelka
participants (3)
-
Alon Bar-Lev -
Eyal Edri -
Jiri Belka