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

[Gene Czarcinski]

On 04/11/2013 08:45 AM, Gene Czarcinski wrote:
> 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.
>
Test results:  mixed.

Some of this may be that I lack understand just where stuff should 
and/or should not work.

1.  RPM: works.  Since the spec file includes running "pythton setup 
configure', ther is a virtcli./cli.cfg file and prefix=/usr
      Since there is no requirement (as far as I know) that stuff 
installed into an rpm-build-rrot has to actually work/execute in the 
rpm-build-root, this is OK and the resulting "binary" rpms install with 
files located properly and the wrappers hard-code point to 
/usr/share/virt-manager.

2. after python setup.py build ... the wrapper files in the ./build 
directory do not work because the point to the hardcoded 
/usr/shar/virt-manager/

The following tests also apply to autobuild.sh which indicates that a 
patch is needed to autobuild.sh.

3.  configure not run (there is no virtcli/cli.cfg file)
      python setup.py install --root=$AUTOBUILD_INSTALL_ROOT
results in bad wrapper files with hardcoded /usr/share/

4.   python setup.py configure --prefix=$AUTOBUILD_INSTALL_ROOT
and
       python setup.py install --root=$AUTOBUILD_INSTALL_ROOT
results in bad wrapper files AND bad directory tree.

5. looks like a winner:
       python setup.py configure --prefix=$AUTOBUILD_INSTALL_ROOT
and
       python setup.py install
results: wrapper files work and good directory tree.

Gene