On 11/02/2015 03:32 PM, Adam Williamson wrote: > 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 Ah... this is a good idea... I wish I would have thought of it. > """ > > 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. > Boy... I do wish we had the conversation two days ago! :-) I really didn't have any ideas on how to do this gracefully, which was the purpose of this email to be begin with... I've changed soname in the past so I know how painful it can be... Last week, instead of us talking about graphics cards and gaming machines... maybe we should have been talking about soname changes! ;-) steved. P.S I am working feverishly on trying to Humpty Dumpty back together again! -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct