On 12/04/2012 10:58 AM, John Reiser wrote: > On 12/04/2012 07:07 AM, Tom Callaway wrote: >> On 12/04/2012 08:38 AM, Fedora Branched Report wrote: >>> Compose started at Tue Dec 4 09:15:31 UTC 2012 >> >> VICTORY! NO BROKEN DEPS in Fedora 18! >> >> Now, I ask you all, please, please. Help me keep it that way! > > Congratulations! Thank you, Tom! This merits an award! > > As part of your acceptance speech, please summmarize, point to, > and/or provide gentle instruction on what package maintainers > should do (and not do), and how to diagnose and recover from mistakes. > I believe that this will help preserve your victory. An excellent suggestion. I will attempt this! If you're building an update for Fedora, and it has shared libraries or versioned provides, look to see if any of the shared library versions have changed (or if the versioned provides have changed). Then, use repoquery to see if any other packages will be affected. If the answer is yes, consider holding on pushing that update until you can either rebuild those dependent packages or coordinate with their maintainers to accomplish this. Bodhi will let you temporarily tag your package as an override to get these builds done. (As an aside, the plan for Bodhi 2 is to not permit updates to push into the repo when it would result in broken deps.) Listen to koji. If one of your packages has a broken dependency, koji will send you an email like this: Subject: Broken dependencies: gambas3 gambas3 has broken dependencies in the F-18 tree: On x86_64: gambas3-3.3.3-1.fc18 requires libkitchen_sink.so.8()(64bit) On i386: gambas3-3.3.3-1.fc18 requires libkitchen_sink.so.8 ***** Now, what that usually means is that kitchen_sink has been upgraded in the Fedora 18 branch, and your package is linked against the old version. In 9 out of 10 cases, simply incrementing the Release, adding a new %changelog entry, and rebuilding your package will resolve the issue. Sometimes, you'll see a version appear here, this happens if your package has a hardcoded version Requires and the version no longer matches. You'll need to check to see if the new version is also supported, and if so, adjust the versioned Requires, increment Release, add a new %changelog entry, and rebuild. Rarely, this occurs when one of your dependencies has been retired or blocked for some reason. You can check to see if a package has been blocked by running: koji list-pkgs --package $PACKAGENAME --show-blocked (where $PACKAGENAME is the name of the dependent package) In case that happens, you either need to unretire (and claim ownership) of the dependency, rebuild your code without it (may not be possible), or retire your package. Documentation for these choices are here: https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package_Procedure https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life I strongly encourage testing new package builds locally first (either in mock or with fedpkg local). I keep VMs for all active Fedora branches so that I can quickly test a build and troubleshoot failures. Don't be afraid to ask for help, either here on this mailing list, or on IRC (#fedora-devel). Lots of provenpackagers exist and we're usually happy to help. Also, be sure to ensure that any change you make in a released (or branched) Fedora, you also reflect in rawhide (and kick off a new rawhide build). Finally, keep rawhide up to date with the latest bits from upstream! We're a lot more forgiving of broken deps (in the short term) in rawhide. hth, ~tom == Fedora Project -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
