repository breakage

[Jeff Spaleta]

On 11/26/05, Greg DeKoenigsberg <gdk at redhat.com> wrote:
> I suppose it might make sense to offer a flag to warn instead of fail for
> dependency errors, but I'm not even sure about that; even experienced
> users can put themselves into a world of hurt by ignoring broken deps that
> turn out to be important down the line.  One of the great things about
> strict depsolving is that you've got a clear path, and either you're on
> the path, or you're not.

No, an option to warn would be abused as a catchall option to use to
avoid all error messages. With all the different repo configurations
in the wild, errors that drive discussion and bugreports are going to
be the only way to catch some of the inter-repo failures. The exclude
option exists to get around dep issues, and can not be generally
abused as a catchall to prevent all error messages in the future.


> Now, the corollary is that it's the responsibility of the repo maintainers
> to keep the path tidy at all costs -- and if we're having problems doing
> that, we need to figure out why.

Today's issue is about how closely one follows upstream in Extras.
This will always be a problem in Extras unless Extras moves to a
point-release model like Core.  Extras is "rolling" with no policy
with regard to how static libraries should be through an Extras
release timeframe.  The more frozen libraries are, the easier it is to
avoid these types of problems, but you lose the ability to track
upstream library development closely in time.

-jef