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

[Lalatendu Mohanty]

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

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.

Thanks,
Lala