Revisiting non-rawhide chain-builds

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed 10 Apr 2013 05:34:48 PM EDT, Adam Williamson wrote:
> On 10/04/13 07:58 AM, Stephen Gallagher wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On Wed 10 Apr 2013 10:59:03 AM EDT, Tom Callaway wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>> 
>>> On 04/10/2013 09:08 AM, Stephen Gallagher wrote:
>>>> 
>>>> Historically, chain-builds were only supported in the
>>>> Rawhide branch because it was the only location that could
>>>> auto-generate the buildroot.
>>>> 
>>>> However, the modern version of bodhi now supports allowing
>>>> users to submit individual packages to the buildroot of any
>>>> branch.
>>>> 
>>>> It would make life easier for a great many people if 'fedpkg 
>>>> chain-build' could gain the capability to automatically
>>>> submit buildroot overrides on non-Rawhide branches.
>>> 
>>> My only concern with this is that on non-Rawhide branches,
>>> these overrides are temporary. I'd hate for this to result in
>>> incomplete update pushes.
>>> 
>> 
>> I don't really see how that would be any worse than the current 
>> situation where updates sometimes land in stable before their 
>> dependencies do (because Bodhi doesn't yet support listing other 
>> updates as dependencies).
> 
> We've probably been round this roundabout before, but updates are 
> supposed to be internally consistent. If an update to Package A
> also requires Package B to be updated, both packages should be
> submitted as a single update. You should not submit one update for
> A and one for B. When I catch these cases, I file negative feedback
> until the updates are corrected.
> 

The classic response to this is that it means that in order to produce
an update, you must be a package owner for all packages in that set
(or else a provenpackager).

As a hypothetical example, let's take openlmi-storage, which is a
management tool that depends on blivet (which is the storage library
provided by the anaconda project). I have a new version of
openlmi-storage that depends on a new version of blivet. I am unlikely
to be a co-owner of blivet. With our current policy, my choices are
"find a provenpackager to submit all packages as a combined update"
(often difficult and requires negotiation with every package in the
set) or "submit my package and make sure to wait until all
dependencies hit stable" (which is error-prone).

And we have the reverse problem as well. I can recall multiple
situations where we introduced serious (and in one case, nearly
catastrophic) regressions in the nss crypto library because it was
bundled with a Firefox update. Firefox updates almost never even make
it into the update-testing push before getting auto-karma into stable
because of the high usage. So now we haven't gotten appropriate
testing for all of the packages in the set.


> I think it might be possible for a sufficiently sophisticated
> version of the proposed mechanism to help the packager out with
> doing this, in fact: it could help you do a chain build and then
> submit an update containing the full chain/set of packages.

I'd certainly be in favor of that. But as I said above, I don't see
how what I originally proposed is functionally any worse than things
are now. It's following the exact same process, just taking some of
the needless drudgery out of it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlFmtRYACgkQeiVVYja6o6PLigCgmgDNE7gl6Am0JIrMBrCfzU3L
IjkAn0HAxevba9ZQ/epdbLiBOWV8jyIh
=DiC6
-----END PGP SIGNATURE-----