[Gluster-users] [Gluster-devel] Dependency issue while installing glusterfs-3.6beta with vdsm

[Kaleb KEITHLEY]

On 10/29/2014 07:34 AM, Lalatendu Mohanty wrote:
> On 10/29/2014 04:22 PM, Niels de Vos wrote:
>> On Wed, Oct 29, 2014 at 06:27:54AM -0400, Humble Chirammal wrote:
>>>
>>>
>>> ----- Original Message -----
>>> | From: "Niels de Vos" <ndevos at redhat.com>
>>> | To: "Humble Devassy Chirammal" <humble.devassy at gmail.com>
>>> | Cc: "Anders Blomdell" <anders.blomdell at control.lth.se>,
>>> "Gluster-users at gluster.org List" <gluster-users at gluster.org>,
>>> | "Gluster Devel" <gluster-devel at gluster.org>, "Humble Chirammal"
>>> <hchiramm at redhat.com>
>>> | Sent: Wednesday, October 29, 2014 1:52:35 PM
>>> | Subject: Re: [Gluster-devel] [Gluster-users] Dependency issue while
>>> installing glusterfs-3.6beta with vdsm
>>> |
>>> | On Wed, Oct 29, 2014 at 09:26:36AM +0530, Humble Devassy Chirammal
>>> wrote:
>>> | > Rebuilding related packages looks to be a solution , however it
>>> may not be
>>> | > possible for each and every release builds of GlusterFS. lets
>>> discuss it in
>>> | > community meeting and act.
>>> |
>>> | No, these rebuilds are only needed for major releases. The SONAME for
>>> | libgfapi is not supposed to change in a stable release. That means
>>> that
>>> | the next rebuild would potentially be needed when glusterfs-3.7 gets
>>> | released.
>>> |
>>>
>>> Not really. afaict, the SONAME jump can happen if there is a new api
>>> exposed via libgfapi which can happen even in same release version of
>>> GlusterFS.
>> I do not think that is supposed to happen after the release. Minor
>> releases are not expected to add new features, only bugfixes and
>> stability improvements. The release-maintainer for 3.6 will be guarding
>> agains incompatible changes. Possibly libgfapi.so.7.x can add new
>> features if really needed, but those details are documented in
>> https://github.com/gluster/glusterfs/blob/master/doc/versioning.md
>>
>>> As a second thought, What happens if qemu or dependent packages
>>> released a new version in between ? Dont we need to rebuild ?
>>>
>>> Also,  we need to build these related packages for f19, 20 and 21.
>> Yes, when related packages get updated for Fedora 19/20/21, we need to
>> build those packages again.
>>
>> Niels
>>
>>
>
> That means we have to watch related  packages in fedora and should
> rebuild for new versions (minor, major etc).

For Fedora we send an email to the Fedora -devel list warning of the 
SO_VERSION bump and the owners of those packages are responsible for 
rebuilding.

Same for EPEL, except we don't have GlusterFS in EPEL.

>
> Niels,
>
> Is there any way we can automate this? may be in in copr  Else it is an
> overkill  for packagers.
>
> What about EL6 and EL7 , do we have any plan for it? We can handle it in
> CentOS Storage SIG by rebuilding packages. But plan to add 3.6.0 there
> after GA.