On 04.08.2008 17:39, Seth Vidal wrote:
On Sun, 2008-08-03 at 09:17 +0200, Thorsten Leemhuis wrote:
I suppose a lot of users won't look that close and some GUIs will likely
hide such a output. So I don't like that idea to much, as it afaik could
block important updates of certain packages for months or years if the
user has a local packages (an orphan or a manually installed RPM from
non-Fedora repos) installed that is the culprit for the dependency problem.
What IMHO might work is a "skip broken" plugin that for example ignores
broken deps for a certain timeframe (say 48 oder 72 hours after the
problems was hit for the first time) and boils out after that in case
the broken dep still isn't fixed.
> [...]
2. doing it via date is very odd. If only b/c the only date we could use
if the file timestamp of the pkg and packages will sometimes sit in a
space before being pushed to a repo officially. So it will be something
of a crapshoot what it says is really broken or not.
That why I didn't suggest to use the build date and mentioned to use "48
or 72 hours after the problems was hit for the first time". That of
cause would need to be managed on the client (e.g. for each broken dep
write down somewhere when the problem showed up; if the same problem
shows up with the same packages 72 hours later then boil out to make
sure the user gets aware of the issue).
But yes, agreed, using the date is a bit odd, but I'd say it could solve
the "Skip broken for weeks prevented that I didn't get the crucial
update" problem. Or is there a better way around that?
Cu
knurd
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list