[HEADS UP] Upcoming soname change for libtirpc

[Adam Williamson]

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

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. 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)".
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net