On Sat, 14 Aug 2010 11:33:02 +0200, Kevin wrote: > > I've always warned about mass-pushing updates to multiple dists, > > and I'm glad I'm not the only one. > > EPEL is an entirely different matter, since: > * there are literally YEARS between the RHEL releases and > * RHEL has a very conservative update model, exacerbating the differences > between releases. > > This kind of trouble is much less likely in Fedora (proper) than in EPEL. IMO, that's splitting-hairs. Since I don't have the time to fill this list with dozens of messages, probably this one will be the last for today in this thread. It doesn't matter much if it's "less likely" or "likely". We've had minor version upgrades of libraries that broke the API and the ABI and lead to app misbehaviour at run-time. Syncing all of Fedora N with Fedora N+1 is not an option, or else we would arrive at the rolling-release model and would not need to prepare "final releases" and distinguish between Fedora N and N+1. If only *some* components are replaced after the final dist release, we basically need to redo the integration testing for each and every update. And that hasn't been done so far. Not for changes in Python modules, and not for other packages either. Broken deps are just the tip of the iceberg. An unresolvable dep is a show-stopper, as it makes installing an update impossible. But packagers, who mass-build upgrades to multiple dists and mark them "stable" without testing for each of the targeted dist, make it worse. It's a packager's attitude problem. Mass-building updates for multiple dists bears risks. Adding EPEL as additional target for the same updates adds an extra problem. [Currently, some EPEL packagers admit they haven't done any testing at all because they don't run a corresponding EL dist installation.] P.S. I'm not completely positive about the extra hurdles in bodhi either (or crap like inheritance of Update Notes), but that is unrelated to my view about "testing" and lack thereof. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel