On Mon, Jun 25, 2007 at 10:36:25PM -0400, Jeremy Katz wrote: > On Tue, 2007-06-26 at 03:49 +0200, Axel Thimm wrote: > > On Mon, Jun 25, 2007 at 09:20:16PM -0400, Jesse Keating wrote: > > > On Monday 25 June 2007 21:15:49 Axel Thimm wrote: > > > > That was one of the three options ;) > > > > > > > > I think a security-updates would not be bad, but maybe not in this > > > > cycle, there's lot to do in short time and having a Fedora > > > > enterprise-like stable branch with security updates isn't Fedora's > > > > typical usage scenario. > > > > > > It's a tough thing to provide, and it would require anybody building a > > > security update to build in two collections, potentially having multiple > > > branches per release, one for "head" and one for "security", etc.. I think > > > it's totally outside the scope of the Fedora project. > > > > I don't think it would require to build twice or open up several > > branches, though, once against release & other security updates would > > be enough. > > > > This assumes of course that FX at the end of its life is still > > (mostly) *backwards* (!) compatible to FX at release time. Fedora's > > pace and release cycle are balanced to not allow this to happen. For > > example for F7 we even dropped mass-rebuilds, because we assumed that > > not only FC6+updates is compatible to FC6 w/o, but even to F7. > > > > While dropping mass-rebuilds was a mistake, this at least demonstrates > > that the Fedora model is not supposed to become backwards incompatble > > with itself within a release. > > > > So the implementaion would be just another tag in koji. The maintainer > > would have to fire a `make build-security' to have koji shove the > > build into the proper tag which would inherit only release and not > > updates. updates-candiates etc. would inherit from security. In fact > > it looks like koji's model has already been planned to allow for this :) > > So, what happens when I have a package which I've previously updated and > now need to do a security update for. The security problem applies to > the original release. Either I have to > a) Build twice > b) Just push the newer security+otherstuffupdate. Which may depend on > other non-security things. No, there are two cases you need to distinguish: a) the previous update of foo picked a new update from say glib and friends which wasn't really required for updating foo. The security update of foo would build just the same under the non-updated glib from the beginning of the cycle. No harm done, as we assume that glib and friend continue to be *backwards* compatible. b) The security update really needs the newer glib or some other entity. In this case it doesn't matter if foo has been updated already before or not. Any required depednency needs to be elevated to be included in the security updates repo (e.g. simply tagged as such). So in fact whether foo has already been updated or not, doesn' really matter, what matter is whether the current security update of foo needs to pull in BR/R of other packages as well. Missing BRs would be noticed at once, since the build would not complete. Missing runtime depdencies would be caught by repoclosure/mash whatever tool will check that "release" is sane, as well as "release + *-updates" is sane as well. > *This* is why the security plugin makes sense. Although it doesn't > guarantee that you only get security changes, it lets you get just > security changes + anything they depend on. At basically no cost to > maintainers, testing, etc There is no such thing as circumventing testing :) The plugin would be able to only do two modes, which you can do also by manually splitting the repo (in fact whether we talk about an actual repo or a virtual repo as seen by a plugin is irrelevant for the arguments above, the negative side of the plugin is that it only works with yum, the positive is that you have a marketing and a placebo effect that it should work) a) only pull in the security updates and the really neccessary dependent packages (like foo requiring glib >= version). This leads to the missing symbol syndrome due to moving packages from the future to the past. b) pull everything the security updates depend on thus a firefox security update would probably pull in the whole updates repo. So no plugin, no matter how intelligent, or even a complete yum rewrite will really save you from keeping security updates in their own (virtual) repo and the most importnat part: pull BR's *only* from release + security-updates repo. The only question that is open is whether the rest of the updates-released can rely on these packages or would need a rebuild, and again: as long as Fedora remains backwards compatible to itself within a maintenance cycle this is not a problem. -- Axel.Thimm at ATrpms.net
Attachment:
pgp1Wua9lHKTk.pgp
Description: PGP signature
-- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers
-- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
