-----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----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
