repository breakage

[Alex Lancaster]

>>>>> "VS" == Ville Skyttä  writes:

VS> On Sat, 2005-11-26 at 08:39 +0100, Ralf Corsepius wrote:

>> > Unless there is a reason to, can we *please* refrain from
>> updating > packages that change a shared library version?

VS> ...and anyway when the need to roll such an update arises, it
VS> should be announced on fedora-maintainers and/or here beforehand
VS> so people have time to prepare.

Yep, and I opened up a bugzilla on directfb on this very issue:

http://bugzilla.redhat.com/174245

Maybe there could be a repoquery run on the combined Extras+livna
combination before an upgrade so problems could be spotted before they
bite users.  Perhaps just running the query to get a list of
Extras packages that are depended-on by livna packages, so that
maintainers of the Extras packages can be made aware of the potential
breakage issues and therefore more carefully co-ordinate with the
livna folks.

>> > In this case mplayer (from livna) is the only issue for me -
>> hopefully > they will rebuild, but IMHO this should NOT have
>> happened unless there > was a darned good reason for the update.
>> xine (from livna) has the same issues.

VS> Actually it's xine-lib, but FWIW, both issues have already been
VS> reported there.

>> That's what I consider a bug in yum: Why can't yum simply ignore
>> such broken deps and just warn about them instead of erroring out?

VS> Seconded, no need to rub it in end users faces.

There is a bugzilla on yum on this, the bottom line is that Seth
thinks it's a bad idea to continue if any package in the transaction
fails (I'm unclear on the reason(s)):

https://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=296

It seems that given that the presence of any third party repos that
can block FC+FE security updates (and even FC updates can sometimes be
blocked by FE packages that haven't been upgraded!), wouldn't a
prudent approach be to allow at least the packages that aren't blocked
be upgraded and hold back the other ones (as apt-get does)?

Alex