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

[Cole Robinson]

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.
> 

Setting it at install time, while it's the 'python' way, has its own problems:
you either have to use guessing code like you've posted, or you have to
actually 'build' some files at time of 'install', which can cause issues if
you do 'sudo python setup.py install' since you now have root owned files in
your directory.

Really the only proper way is to do the autotools ./configure split which I've
tried to recreate here.

> 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.
> 

That is not anything we should care to support: all autotools projects that
have code ependent on ./configure --prefix will not run as expected from an
RPM build root.

> 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.

Agreed, that's basically why I was punting on the problem by just hardcoding
/usr initially. My recommendation would be to just make it work sufficiently
for your needs and not worry about every corner case since you will quickly
drive yourself mad.

Thanks,
Cole