Proposed package blocking due to FTBFS

[Matt Domsch]

On Tue, Dec 07, 2010 at 02:10:00PM -0500, Orcan Ogetbil wrote:
> On Tue, Dec 7, 2010 at 12:01 AM, Matt Domsch wrote:
> > I would like to propose blocking packages at the F15 alpha compose
> > point if they have not resolved their FTBFS from F14 or earlier. ??The
> > lists may be broken down by when they last did build. ??With 3
> > exceptions, these 110 bugs are all still in NEW state as well, so they
> > haven't had much maintainer love in quite some time (6-18 months).
> >
> 
> The subtlety here is that a FTBFS does not imply the package is not
> functional. A package may be FTBFS due to various trivial reasons,
> e.g. the name of a BuildRequires has changed and the new BuildRequires
> does not Provides the old one. In such cases, from the functionality
> perspective, the package does not need a rebuild.
> 
> Note that I am not advocating keeping these packages unfixed. I wanted
> to point out that things might turn ugly and might even trigger an
> avalanche when you remove the FTBFS packages from the repo and then
> the packages that depend on them will start to cry.

skvidal pointed out repoquery --tree-whatrequires can help us find the
whole affected set of packages.  I'm looking at generating that list
now.  If we include all ~550 orphan packages in the run, plus the ~100
FTBFS packages, plus all packages that these depend on, I'm sure it'll
wind up being a long list.  All the more reason to look _now_, and not
2 days before Alpha compose.

I believe keeping the distribution self-hosting (meaning, it can build
itself) is an important goal. When we have packages that no longer
build, either through their fault or through the fault of one of their
dependencies, we lose the ability to be self-hosting, and I question
the value of being open source if we can't use that source anymore.


-- 
Matt Domsch
Technology Strategist
Dell | Office of the CTO