Dne 20.6.2014 15:52, Chuck Anderson napsal(a):
On Fri, Jun 20, 2014 at 02:39:25PM +0200, Dennis Jacobfeuerborn wrote:
On 20.06.2014 14:11, Reindl Harald wrote:
Am 20.06.2014 14:04, schrieb Tim Lauridsen:
On Thu, Jun 19, 2014 at 8:47 PM, Dennis Gilmore <den...@ausil.us
<mailto:den...@ausil.us>> wrote:
In testing dnf on rawhide I nearly always do "dnf clean metadata && dnf
update" purely because I found most of
the time dnfs metadata was out of date. To me dnf fetching the metadata
behind the scenes just doesn't work
right. But I'm not sure that me or rawhide fits into the experience dnf is
trying to give.
Dennis
Dnf-0.5.2 has a --refresh option, there will a check if the repo metadata is
newer than the cached one.
so.
dnf update --refresh will check and update metadata if needed
*that* would be a useful default instead background-refreshes
I think these are two separate issues. Independent of the background
refreshes dnf should always check if its current view of the world is
up-to-date (that is the data in its cache is current).
This can be fairly important when it comes to security issues. When a
fatal exploit is fixed in a package you don't want dnf to say that there
are not updates available when this is in fact not true.
Agreed. In fact, when I'm doing updates (which doesn't happen as
frequently as it should due to the disruption to work it causes) I
want to be absolutely sure I'm not working out of a stale cache--I
often do "yum clean expire-cache; yum update" since I know I can trust
that to give me the latest updates. It would be nice if I could just
trust dnf to do the right thing without resorting to extra command
line arguments.
Well I'm still curious why everyone solves upgrade of metadata, but every
developer of yum and dnf stays pretty much away of any 'error-case' handling
situation.
So whenever there is some crash fault during upgrade the installation is left
broken in the middle - and after decades of rpm/yum development there simply
doesn't exist tool to fix it. So yes - skilled user will deal with that, but
I'm pretty sure any unskilled one is directly heading to reinstall...
Also for years Debian supplies short update 'diffs' - so user doesn't have to
download multiple MB sized files - just couple short small files - again
something much nicer then running a daemon to download tens of MB on
background daily...
Zdenek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
