-----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-----