[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: repository breakage
- From: Alex Lancaster <alexl users sourceforge net>
- To: fedora-extras-list redhat com
- Subject: Re: repository breakage
- Date: Sat, 26 Nov 2005 05:31:37 -0800
>>>>> "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
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]