Legacy in Build Roots

Michael Schwendt bugs.michael at gmx.net
Sun Jul 2 10:46:44 UTC 2006


On Sat, 1 Jul 2006 22:23:46 -0500, Dennis Gilmore wrote:

> Hey all,
> 
> I put in a request and was asked to take it here.  What i want is to make sure 
> that FC3 extras packages have legacy updates in the build root.  This will 
> also include FC4 legacy updates soon.
> 
> Why do i want this.  
> 1) while hopefully not likely its possible a legacy update will break a extras 
> package.
> 2)  if something is statically linked and legacy fixes a security issue we 
> need a way to build against the fix.
> 3)  it will ensure that things are nice and clean  as it should be the same 
> environment that is in use.
> 
> 
> Some of you will say  i don't care about older releases. as things stand right 
> now.  Extras are responsible for extras packages until A release is declared 
> EOL.  Right now FE3  is not EOL.  If  you as a maintainer don't fix security 
> issues in older releases then  the security team has to do it.  When  Legacy 
> takes over core they do not take over extras.  does this mean you need to 
> release an update for every branch everytime you have a new version?  no.  
> but what you should care about is at the very least security issues. 

The open questions and the reasons why I find it necessary to talk more
about it and to see a couple of things carved into stone:

Fedora Legacy is a team of volunteers who enlengthen the life of old FC
releases. Who will do the same for old FE branches? Recall this:
  https://www.redhat.com/archives/fedora-extras-list/2006-April/msg01650.html
(Don't answer "the Security Team" right now. Read on.)

Fedora Legacy has been an optional thing so far. A repository to enable
manually. For anyone getting FC+Updates from official Fedora download
locations or mirrors, there has not been any Fedora Legacy in there so
far, e.g. http://wftp.tu-chemnitz.de/pub/linux/fedora-core/updates/3/i386/

Will Fedora Legacy Updates enter the primary download location of Fedora
Core Updates, so the transition would be transparent? There are no clear
details about whether this will be done:
  http://fedoraproject.org/wiki/Board/Meetings/2006-06-06
There's only a vague suggestion that legacy updates may be pushed
to download.fedora.redhat.com, not that they will go into the
existing updates folders. (it would also become necessary to merge
bugzilla, btw)

Any FE packager, who still wants to support all his FE packages, now must
track Legacy and test current and future packages appropriately as legacy
upgrades may break things at run-time and/or build-time. Unless Legacy
Updates remain in a separate repository and are not merged with FC
Updates. In that case, FE packagers would face two targets, however.

Conclusively, we would need a policy that Fedora Legacy becomes mandatory
for old FE branches, which are in maintenance state. When the FE buildsys
enables Legacy packages, it must be mandatory that the packagers track
Legacy Updates and test their packages appropriately.

With regard to
  https://www.redhat.com/archives/fedora-extras-list/2006-April/msg01650.html
there doesn't seem to be any signs of the security team in the Wiki yet.
Who is on the security team and will take over maintenance of old FE
branches? I'd like FE packagers to be able to drop their old FE packages
and re-assign incoming bug reports to those, who will keep them current
with Legacy.

Previously, the Fedora Legacy team has not shown any interest in doing or
participating in legacy updates for FE. But now that the FE buildsys would
include their packages, they would have a direct influence on old FE
branches both at build-time and run-time. Unlike before, the Fedora Legacy
maintainers need to take extra precautions that they don't break FE
because they look only at FC. It is vital that there is a clear
announcement about who will take care of any induced breakage in FE
(including broken upgrade paths due to inappropriate EVR, and upgrades
requiring a chain of upgrades in FE).




More information about the Fedora-maintainers mailing list