Plan for Today's (20070625) Release Engineering meeting

[Axel Thimm]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20070626/49c3779a/attachment.sig>