[virt-tools-list] [PATCH-v5.5 3/5] make wrapper executables work

Gene Czarcinski gene at czarc.net
Thu Apr 11 12:45:39 UTC 2013


On 04/10/2013 06:32 PM, Cole Robinson wrote:
> On 04/09/2013 03:19 PM, Gene Czarcinski wrote:
>> 1. Add virtcli to data_files[]
>>
>> 2. Add code to wrapper created in my_build() to determine
>> the directory the wrapper script is located and then
>> execute the python program which is located relative
>> to that directory.  For real system installs, this
>> directory will be "/usr/bin".
>>
>> 3. Update virt-manager.spec for the virtcli directory.
>> .
>> Signed-off-by: Gene Czarcinski <gene at czarc.net>
>> ---
>>   setup.py          | 18 ++++++++++++++++--
>>   virt-manager.spec |  1 +
>>   2 files changed, 17 insertions(+), 2 deletions(-)
>>
>> diff --git a/setup.py b/setup.py
>> index e98561e..6186316 100644
>> --- a/setup.py
>> +++ b/setup.py
>> @@ -81,10 +81,23 @@ class my_build(build_extra):
>>               os.mkdir("build")
>>   
>>           for app in cmds:
>> -            sharepath = os.path.join(cliconfig.asset_dir, app)
>> +            sharepath = os.path.join("../share/virt-manager", app)
>>   
>>               wrapper = "#!/bin/sh\n\n"
>> -            wrapper += "exec \"%s\" \"$@\"" % (sharepath)
>> +            wrapper += """
>> +SOURCE=\"${BASH_SOURCE[0]}\"
>> +# resolve $SOURCE until the file is no longer a symlink
>> +while [ -h \"$SOURCE\" ]; do
>> +  DIR=\"$( cd -P \"$( dirname \"$SOURCE\" )\" && pwd )\"
>> +  SOURCE=\"$(readlink \"$SOURCE\")\"
>> +     # if $SOURCE was a relative symlink, we need to resolve it
>> +     # relative to the path where the symlink file was located
>> +  [[ $SOURCE != /* ]] && SOURCE=\"$DIR/$SOURCE\"
>> +done
>> +DIR=\"$( cd -P \"$( dirname \"$SOURCE\" )\" && pwd )\"
>> +
>> +"""
>> +            wrapper += "exec \"$DIR/%s\" \"$@\"" % (sharepath)
>>
> I don't like this shell bit here: even if it's simple, shell maintenance is a
> total pain.
>
> What I did here is add a --prefix switch to configure: this makes it work
> similar to an autotools project. install will warn if it is passed an explicit
> --prefix which doesn't match the one that configure has. We could probably
> find a way to have 'install' re-run configure but I'll see if anyone cares first.
>
> I pushed the other bits as a standalone commit:
>
> https://git.fedorahosted.org/cgit/virt-manager.git/commit/?id=2a7a634df0547ca0a7c9c3440c9049c7ecabab1e
>
> Thanks,
> Cole
I agree that have the shell-script code is a pain but this was the only 
way I could find that actually worked.  The original code creates the 
files at build-time and there is just not enough info at that time to 
determine the runtime environment/paths that would exist.

There is nothing in build, install, or autobuild.sh which says that 
configure can or must be run.  Therefore, I assumed that putting 
something there was not appropriate.

My criteria was that it should work:

1. if python setup.py install is run

2. if autobuild.py is run in the git-clone-repository

3. if autobuild.py is run in an directory-tree created by expanding a 
tarball created by sdist

4. If binary rpms and created an installed

I may not have liked my kudgy solution but it works for every variation 
I could think of.

If I understand your solution correctly (add --prefix to configure), a 
configure must be run before install or run by install.

FWIW, I believe that a "good" solution would be to set the path at 
install and not build time.  However, then the question arises about 
RPMs.  rpmbuild will "install" into the rpm-build-root but the path in 
the wrapper must ultimately reflect where the RPM will be installed and 
not where it is built in build-root.

What my kudgy solution does which (I beleive) the configure--prefix does 
not do is be able to correctly execute the wrapper when it is in the 
rpm-install-root (or the autobuild.sh root) but that same wrapper will 
correctly execute when installed in /usr/bin.

What I did not know is the conditions under which things had to work so 
I made sure they worked in "all" conditions.

For such a "minor" things, this is sure one big PITA.

Gene




More information about the virt-tools-list mailing list