Stable Release Update Regression/Build Problem

[Scott Kitterman]

On Mon, 23 Jun 2008 23:16:07 -0700 Steve Langasek 
<steve.langasek at ubuntu.com> wrote:
>On Mon, Jun 23, 2008 at 11:17:37PM -0400, Scott Kitterman wrote:
>> An SRU for aptoncd was just moved from hardy-proposed (where it worked) 
to 
>> hardy-updates where it does not due to a pending python-central SRU.
>
>> https://bugs.launchpad.net/ubuntu/+source/aptoncd/+bug/199600
>
>> The aptoncd package was apparently built against python-central 
0.6.7ubuntu0.1 
>> in hardy-proposed which produces a versioned depends on python-central 
>> (>=0.6.7) but 0.6.5ubuntu1 is all that is currently available in Hardy's 
>> release pocket.
>
>> I'm not sure if there are other packages that use python-central in 
>> hardy-proposed, but none should be pocket copied from hardy-proposed to 
>> hardy-updates until python-central gets moved.
>
>> Filed in launchpad as bug 242554.
>
>> https://bugs.launchpad.net/ubuntu/+source/aptoncd/+bug/242554
>
>Scott got ahold of me on IRC shortly after sending this email, and I've
>followed through on the python-central SRU candidate which has now been
>validated and copied to hardy-updates.
>
>I've marked bug #242554 as 'fix released', as the dependency of aptoncd
>should now be satisfiable within hardy-updates as soon as the package has
>been published and the mirrors catch up.
>
>This highlights the need for a check as part of our SRU process to verify
>that packages which are being copied into -updates won't cause
>uninstallability problems.  python-central is not a unique case in
>warranting such a check; whenever an ABI-changing kernel SRU is done, it's
>important to be sure that all the packages are copied as a group to avoid
>regressions in installability such as this, and currently this check is done
>entirely by hand.
>
>An appropriate follow-up to prevent this problem from recurring would be to
>implement such a check.  Perhaps britney is the right starting point for
>this?
>
Another related issue is the question of running with *-proposed enabled 
versus installation  of single packages from proposed.  This package could 
have only passed verififcation if *-proposed was enabled on the system in 
question.

While running with *-proposed enabled may have some benefit for regression 
detection, I don't think it is suitable for SRU verification.  Generally, I 
the verification should be against *-release and *-updates without other 
packages from *-proposed.  It is feasible to mechanize installability 
checks, but more subtle package interactions need to be explored during the 
verification process.

Unless someone objects, I'll update the SRU process to reflect this 
requirement.

Scott K