[HEADS UP] Upcoming soname change for libtirpc

[Adam Williamson]

On Mon, 2015-11-02 at 14:59 -0500, Steve Dickson wrote:

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

Thanks a lot. It just is a bit frustrating to multiple teams -
anaconda, QA, and releng are all working on making Rawhide more of a
known quantity, and this kind of things breaks it for all of us.

> > 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? 

Yes. What could - and should - happen during the week is you could run
test builds of the affected packages, and find these problems, and then
hold off on doing the build in Rawhide until resolutions were
available. There are various strategies for that. The casual way I'd do
it would be to do a scratch build of libtirpc , download the results,
make a side repository, and do mock builds of the dependent packages.
It's easy to create a mock target which uses a local side repository:
you just copy the config file for an existing target and add an
additional repository definition to it right at the bottom, above the
closing """, like this:

[side]
baseurl=file:///home/adamw/local/repo2/x86_64
enabled=1
"""

That's from my 'Rawhide with a side repo' target definition file,
/etc/mock/fedora-rawhide-x86_64-side.cfg . Mock target names are the
basenames of the config file, so to do a build against that target I'd
do:

mock -r fedora-rawhide-x86_64-side --rebuild some.src.rpm

I'd have the packages I wanted to build against in
/home/adamw/local/repo2/x86_64 and I'd have run 'createrepo .' in that
directory.

You can also request a tag from releng for doing significant bump-and-
rebuild operations like this; that's basically a sorta playground space
in Koji, you can do a build of the soname-bumped library in the tag and
then try building all the dependent packages in the same tag, and none
of the stuff will ever appear in the official repos, unless you
manually tag it across once you're happy with it. Finally, you could
use COPR - just create a COPR, do the soname bumped build, and try
building all the deps in the same COPR. That might be the easiest way.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net