On Wed, Sep 12, 2012 at 01:59:43PM +0200, Marcus Hüwe wrote:
Hi,
On 2012-09-12 13:12:02 +0200, Michal Vyskocil wrote:
On Wed, Sep 12, 2012 at 12:40:16PM +0200, Dirk Müller wrote:
On Monday 10 September 2012, Michal Vyskocil wrote:
The new argument for osc build --host will perform the build on a remote host. It is a shortcut for
Hi Michal,
I think thats a very nice idea indeed. I wonder if your patch handles error cases correctly though (like e.g. rsync not being installed or the remote dir not being writeable).
No, it does not do any error checking. So if rsync is not available, the check_call raises an exception and you will get a "nice" python stack trace. I will extend it, but want to hear some feedback first.
I also like the idea (even though I have never needed something like this so far:) ). What about introducing a new command like "rbuild" for it?
Hi, As long as it will be an alias for build (because you might not want to reimplement every argument for two commands), I've no objections.
For instance the fact is ignores global arguments might be a problem ...
Another question is how a path should be interpreted, for instance --prefer-pkgs /path/to/packages Is this a local path (that is the packages have to be rsynced to the build host first) or is this a remote path (on the build host)? Also what does a user expect when using "build --host ..."? Does he/she expects that the local or remote settings for building are used (examples: extra-pkgs, vm-* etc. config options)?
My thinking is that all build arguments must be handover to the remote osc build command osc build --host foo:~/bar openSUSE_12.1 i586 --> ssh foo "cd ~/bar; osc build openSUSE_12.1 i586 The user should be responsible to use the arguments makes a sense on a remote side, so don't use i586 if we are want to build on arm machine. Or don't want to build using kvm on a machine, where is no kvm available. Or use an argument, which is not available on a remote's osc installation ;-) Reading osc build --help, I would say there are six options needs to be handled carefully * --oldpackages=DIR - I don't know what is this doing, so dunno how to handle it * -k DIR, --keep-pkgs=DIR - this means command must rsync the files back to the local dir - the tricky part is to ensure the remote part stores it in a writable location * -p DIR, --prefer-pkgs=DIR - this means DIR must be rsynced to the remote server - again to some writable location * --overlay=OVERLAY - dunno * --rsync-dest=RSYNCDESTPATH - dunno * --rsync-src=RSYNCSRCPATH - dunno The dunno things might be simply avoided to be used with --host until someone will needs and implement them ;-) There is a part with an environment variables # Note: # Configuration can be overridden by envvars, e.g. # OSC_SU_WRAPPER overrides the setting of su-wrapper. # OSC_BUILD_ROOT overrides the setting of build-root. # OSC_PACKAGECACHEDIR overrides the setting of packagecachedir. I will preffer to deprecate them in favor of build arguments --su-wrapper, --build-root (but is not the --root an alternative?) and --cache-dir, which can be done independently on this change. Regards Michal Vyskocil