Summary

The goal of this spec is to ensure all packages for which we ship binaries have built successfully at least once during the cycle. This will be done both by removing out of date binaries and the binaries of packages that fail to build in a rebuild test and have not otherwise built during the cycle. The rebuild test will be with amd64 and i386. Removals from ports will be inferred from failures on the primary archs.

Release Note

In order to enhance maintainability of this LTS release, Ubuntu is only shipping binaries that we have tested to build at least once during the 10.04 development cycle. As a result, some packages for which there is source in the archive do not have binaries available. As fixes become available, these binaries can be restored via the StableReleaseUpdates process.

Rationale

This is intended to minimize the number of unsupportable packages we ship in 10.04 due to it being an LTS. If it works out well, we may do it for all releases in the future.

User stories

Kees notices a severe security vulnerability announced that impacts a Universe package. He investigates and discovers that while the package can't be built from source, there is also no binary package in the 10.04 archive, so unlike earlier Ubuntu releases, users are not potentially exposed to this risk.

Michael notices tries to install a package he's heard about and discovers there's no binary for it in 10.04. He researches this a bit and finds it was removed because it couldn't be built. He's a bit of an enthusiast and via Google and asking some smart questions, he figures out how to get it to build. He gets the fix uploaded in the development release and then via the StableReleaseUpdates process gets the package back into 10.04. He gets to use the package and has a great sense of accomplishment.

Assumptions

It is reasonable to infer that if a package does not build on i386 or amd64 it won't (generally) build on the ports architectures either.

Design

This will not be applied to the supported architectures in Main/Restricted since they are aggressively maintained.

For packages that are currently FTBFS in the archive, out of date binaries will be removed.

LucasNussbaum has rebuilt the Ubuntu archive using an archive snapshot taken after the Lucid toolchain was up, but before the first autosync. We will use the results of this rebuild test to identify latent build failutres.

The results of the rebuild test will be hosted on qa.ubuntuwire.com and WilliamGrant will expose the results on a similar page to what he's done with other rebuild tests as a community QA resource to help people interested in fixing FTBFS.

Packages which fail the rebuild test and have not subsequently built will have their binaries removed. For packages that fail either amd64 or i386, their ports binaries will also be removed unless they are packages that don't normally build on amd64 or i386 (this will be tested by seeing if they are out of date on amd64 or i386 and not on other architectures).

Before any removals are done, the list will be sent to ubuntu-devel for review.

Migration

We will need to adjust the StableReleaseUpdates process slightly to ensure it's clear FTBFS fixes for missing binaries are SRU candidates. This will be covered in the release notes. We will make an announcement to ubuntu-devel-announce when this is done.

Unresolved issues

Once this is done, it should be considered for future releases. Additionally, policy for when to remove binaryless source should also be considered.

BoF agenda and discussion

Goal: Minimize the number of unbuildable binaries we ship in Lucid for LTS

Why: Packages that need update during the maintenance period for Lucid (security or SRU) can't be updated if they don't build

Identifying the packages:

Rebuild test of Lucid on i386 and amd64

Then what?

Idea:

Issues Solved:

Rebuilds:

Removals:

if the package FTBFS on i386 or amd64 AND there is a current binary for the failing architecture in the archive, remove from the offending architecture and all ports architectures.

Removals are to be procesed with lpremove

Restorations:

Provide list of packages to restore Use regular rebuild & FTBFS lists to track continued failures

During Lucid Cycle:

Packages that built once during Luicid are to be considered recoverable,through normal FTBFS policies

Actions: lucas send build failure logs for hosting on ubuntuwire ScottK to send list of binaries to remove for discussion


CategorySpec

LucidPlatformSupportableBinaries (last edited 2009-11-27 04:37:02 by kitterman)