[PKG-Openstack-devel] liberasurecode/pyeclib v1.0.8

Thomas Goirand zigo at debian.org
Thu Aug 6 07:19:43 UTC 2015


For Debian, there shouldn't be any rpath tweaks, period.

So if in your setup.py you test if you're running on RedHat based
system, and do the rpath tweaks in this environment only, then maybe you
can keep it. However, I'm not convince it's up to each and every lib to
do such a hack, even in a Red Hat based system. So I asked on #rdo, and
here's the result:


<zigo> number80: I mean I'm removing the rpath in Debian:
http://anonscm.debian.org/cgit/openstack/python-pyeclib.git/tree/debian/patches
<zigo> It was there before version 1.0.7
<number80> Pete's patch also includes this
<number80> I don't know why they're playing with rpath, we don't need
this especially for python modules

So effectively, you're doing the wrong things, and I'd advised you to
remove all rpath tweaks, and see with RDO people why there's an issue.

Hoping this helps,
Cheers,

Thomas Goirand (zigo)

On 08/05/2015 09:13 PM, Gohad, Tushar wrote:
> Thanks Thomas.  So I assume this change doesn't need to be in the upstream repo - we can keep the lib64 stuff for Fedora?
> 
>> -----Original Message-----
>> From: Goirand Thomas (aka zigo) [mailto:thomas at goirand.fr]
>> Sent: Wednesday, August 5, 2015 12:12 PM
>> To: Gohad, Tushar
>> Cc: Kevin Greenan; Thomas Goirand
>> Subject: RE: liberasurecode/pyeclib v1.0.8
>>
>> We have multi-arch in Debian, there's no lib64 folder anymore, and it's been a
>> few Debian release like this already.
>>
>> Thomas
>>
>> Sent from my Cyanogen phone
>>
>> On Aug 5, 2015 7:20 PM, "Gohad, Tushar" <tushar.gohad at intel.com> wrote:
>>>
>>> Hi Zigo, question on the rpath patch below:
>>>
>>> Can you explain the rationale behind removing the lib64 handling?  This seems
>> to break on Fedora like systems.
>>>
>>>
>>> Description: More rpath tweak removal
>>> Author: Thomas Goirand <zigo at debian.org>
>>> Forwarded: no
>>> Last-Update: 2015-08-05
>>>
>>> Index: python-pyeclib/setup.py
>>>
>> =============================================================
>> ======
>>> --- python-pyeclib.orig/setup.py 2015-08-05 08:40:04.549702848 +0000
>>> +++ python-pyeclib/setup.py 2015-08-05 08:43:55.692013250 +0000
>>> @@ -95,10 +95,6 @@
>>>      for prefix in ('/', '/usr', '/usr/local', _exec_prefix):
>>>          libdir = os.path.join(prefix, 'lib')
>>>          libdir64 = os.path.join(prefix, 'lib64')
>>> -        if arch64 and os.path.exists(libdir64):
>>> -            default_library_paths.append(libdir64)
>>> -        else:
>>> -            default_library_paths.append(libdir)
>>>      return default_library_paths
>>>
>>>
>>> @@ -223,7 +219,6 @@
>>>
>>>          installroot = install_lib.install_dir
>>>
>>> -        default_library_paths.insert(0, installroot)
>>>          _install.run(self)
>>>
>>>          # Another Mac-ism...  If the libraries are installed
>>> --
>>>
>>>> -----Original Message-----
>>>> From: Gohad, Tushar
>>>> Sent: Wednesday, August 5, 2015 9:49 AM
>>>> To: 'Thomas Goirand'
>>>> Cc: Kevin Greenan; John Dickinson; Luse, Paul E (paul.e.luse at intel.com); PKG
>>>> OpenStack
>>>> Subject: RE: liberasurecode/pyeclib v1.0.8
>>>>
>>>> Hi Zigo,
>>>>
>>>>
>>>>> 1/ Embedded liberasurecode
>>>>>
>>>>> On 08/05/2015 10:04 AM, Gohad, Tushar wrote:
>>>>>> PS:  Please note we have eliminated the "v1.0.8m" style tag altogether
>>>>>> - there is only one version now, with integrated liberasurecode (this
>>>>>> is still required for Openstack CI) - we may be able to get rid of the
>>>>>> integrated version if we can get liberasurecode-1.0.8 installed on the
>>>>>> Openstack Jenkins slave image by default.
>>>>>
>>>>> This isn't good at all. The OpenStack CI gate shouldn't dictate the way
>>>>> you release things. If the gate is broken, fix the gate, don't break the
>>>>> packaging just to fix the gate. Maybe adding some options just for the
>>>>> gate would do? That'd be best, because the OpenStack gate should be
>>>>> considered the exception, and not the general use case.
>>>>
>>>> It is hard to get it right for all - we chose to keep it functioning the way it was,
>> for
>>>> CI check/gate.  As soon as the 1.0.8 .deb packages are in Trusty, we'll get
>> those
>>>> included in the Openstack CI slaves.
>>>>
>>>> (In the past we had to support Centos6 for a slave host OS and didn't have
>> rpms
>>>> available)
>>>>
>>>>>
>>>>> Lucky, with a few patches, it doesn't seem to try building
>>>>> liberasurecode when I build pyeclib 1.0.8. I have attached the patches
>>>>> which I currently use in the PyECLib package. Please consider having a
>>>>> way to integrate these patches upstream (an option to setup.py would do,
>>>>> I'd just add this option to my debian/rules).
>>>>
>>>> We'll add an option to setup.py - we can retag it.
>>>>
>>>>>
>>>>> 2/ rpath tweaks
>>>>>
>>>>> You will notice that I'm removing all the tweaks you're doing with the
>>>>> runtime library path. It is forbidden by the Debian policy to play with
>>>>> that, and for good reasons. Please see this document:
>>>>>
>>>>> https://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-
>>>>> guide.html#rpath
>>>>>
>>>>> (specifically this rpath section, but it's nice if you can take the time
>>>>> to read all of the doc)
>>>>
>>>> I see - we'll retag a 1.0.9 with rpaths removed.  Thanks for the suggestion.
>>>>
>>>>>
>>>>> 4/ Upload
>>>>>
>>>>> Anyway, despite the above issues, I was able to upload both
>>>>> liberasurecode and pyeclib to Debian Sid. Please let me know if you can
>>>>> address some/all of the above issues directly in upstream.
>>>>
>>>>
>>>> Will do.  Thank you.
>>>>
>>>> Tushar (tsg)
>>>




More information about the Openstack-devel mailing list