F-18 Branched report: 20121204 changes

[Tom Callaway]

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