[HEADS UP] Upcoming soname change for libtirpc

[Steve Dickson]

Hello,

On 11/02/2015 02:15 PM, Adam Williamson wrote:
> On Mon, 2015-11-02 at 11:02 +0800, Ian Kent wrote:
>> On Sun, 2015-11-01 at 18:48 +0100, Kalev Lember wrote:
>>> On 10/30/2015 05:36 PM, Kevin Fenzi wrote:
>>>> On Fri, 30 Oct 2015 11:50:48 -0400
>>>> Steve Dickson <SteveD at redhat.com> wrote:
>>>>> 2) find and rebuild all the dependencies?
>>>>
>>>> Should be something like: 
>>>>
>>>> % sudo dnf repoquery --whatrequires 'libtirpc.so.1()(64bit)'
>>>> Last metadata expiration check performed 0:01:17 ago on Fri Oct
>>>> 30
>>>> 10:34:06 2015.
>>>> autofs-1:5.1.1-3.fc23.x86_64
>>>> fedfs-utils-admin-0:0.10.3-4.fc23.x86_64
>>>> fedfs-utils-server-0:0.10.3-4.fc23.x86_64
>>>> libtirpc-devel-0:0.3.2-3.0.fc24.x86_64
>>>> nfs-utils-1:1.3.2-10.fc23.x86_64
>>>> rpcbind-0:0.2.3-0.2.fc23.x86_64
>>>
>>> Now that the libtirpc update is in, I tried to kick off rebuilds
>>> for
>>> these to make them them installable again in rawhide (they are
>>> breaking
>>> nightly image composes). Didn't get very far with this though
>>> because
>>> rpcbind and fedfs-utils are failing to build and are blocking
>>> others:
>>>
>>> rpcbind (http://koji.fedoraproject.org/koji/buildinfo?buildID=69540
>>> 4)
>>> failed with:
>>>
>>> src/rpcb_svc_com.c: In function 'handle_reply':
>>> src/rpcb_svc_com.c:1277:6: error: 'SVCXPRT {aka struct
>>> __rpc_svcxprt}' has no member named 'xp_auth'
>>>   xprt->xp_auth = &svc_auth_none;
>>>
>>> and fedfs-utils (
>>> http://koji.fedoraproject.org/koji/buildinfo?buildID=695402) failed
>>> the same way:
>>>
>>> gss.c: In function 'fedfsd_get_gss_cred':
>>> gss.c:178:23: error: 'SVCXPRT {aka struct __rpc_svcxprt}' has no
>>> member named 'xp_auth'
>>>   auth = rqstp->rq_xprt->xp_auth;
>>
>> Steve is aware of this, or will be soon, as it was raised on the
>> upstream libtirpc mailing list.
>>
>> So we need to wait until rpcbind is updated before we can go further
>> with this.
> 
> Folks, this is not okay. This is not the right way to do things. If you
> aren't reasonably sure that all the library's consumers can be made to
> work with the new version of the library, *don't put the new version in
> Rawhide*. Rawhide isn't a dumping ground for random new code and has
> not been for some time. It is not okay to just break the entire thing
> and say 'we'll fix it once we've finished the upstream work'. The
> upstream work needs to happen *before* you break Rawhide.
> 
> We're doing all this work across several teams to compose and test
> Rawhide regularly, and it's kind of pointless if people are just going
> to break the whole thing gratuitously. Please do not do this.
> 
> Policy:
> 
> https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master
Boy... I sure wish this policy was pointed out earlier... 
I had no idea that existed.. I realize ignorances is not an excuse
so for that I do apologize..     

> Note that that clearly says "A week in advance, notify maintainers who
> depend on their package to rebuild when there are abi/api changes that
> require rebuilds in other packages or offer to do these rebuilds for
> them." *A WEEK IN ADVANCE*. This bump was submitted to Koji on the
> *same day* it was notified, 2015-10-30. 
To be clear.. I should have waited a week after I sent this mail to
bump the version, correct? If so what could the maintainers do during
that week to make things smother? 

steved.

That is a clear violation of
> the policy. I would argue the policy also assumes fairly strongly that
> rebuilds of dependent packages will in fact be possible, but I'd
> suggest we amend the policy to explicitly state that soname bumps and
> other incompatible changes should not be done *at all* unless there is
> a clear plan to make all dependent packages compatible immediately.
> 
> Also relevant in that text: "Feel free to push out the newest version
> of packages as long as they do not cause breakage." and " Try not to
> push a clearly broken build (breaks the default buildroot package set,
> etc)".
>