Re: dnf --refresh reverts to older metadata (was: Re: dnf update vs Software Udpates)

[Michael Schwendt]

On Mon, 24 Aug 2015 16:48:22 +0200, Heinz Diehl wrote:

  https://fedorahosted.org/fedora-infrastructure/ticket/4866
 
 Maybe it's time to take a look at how other distributions do it.
 Arch's pacman has worked for me without any trouble a long time. And
 there is Opensuse  Co..

For such a step, evaluating where we are today should come first, IMO.
Then you can compare with how others do it, whether they distribute
their users to the same number of mirrors world-wide, or whether they
prefer a few mirrors run by passioned admins.

The master repository is updated.

Announcements are mailed out.

Users read an announcement, but they don't see the updates yet.
WTF? Why not? Forum posts around the world suggest yum clean all
and dnf clean all as _the fix_. But it isn't a fix, if the nearby
mirrors don't carry the changed repo contents yet. dnf --refresh
doesn't force retrieval of latest repodata either. (And that it even
reverted to old data is an unrelated bug in the implementation.)
Any automatically triggered check of the metadata would have achieved
the same, if done at the right time. Mirrors not being up-to-date,
nothing new to fetch.

Updates become available as soon as they arrive on the nearby mirrors.
Is that sent as a clear message to all Fedora users? I don't think so.

On average, how long does it take for updates to arrive on the mirrors?
Is anything known here? How long does it take for updates to arrive in
another country? Are there any high-priority mirrors, who likely carry
the latest changes quickly after release? Would it be possible to assign
users to nearby repos in a more reliable way? Questions, questions,
questions.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf --refresh reverts to older metadata (was: Re: dnf update vs Software Udpates)

[Heinz Diehl]

On 24.08.2015, Michael Schwendt wrote: 

 The feedback in the ticket I've opened is not encouraging so far.
 https://fedorahosted.org/fedora-infrastructure/ticket/4866

Maybe it's time to take a look at how other distributions do it.
Arch's pacman has worked for me without any trouble a long time. And
there is Opensuse  Co..



-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf --refresh reverts to older metadata (was: Re: dnf update vs Software Udpates)

[Michael Schwendt]

On Thu, 20 Aug 2015 07:25:48 -0400 (EDT), Honza Šilhan wrote:

 The more I think about it DNF does it right. You should report it to Fedora 
 infrastructure.
 DNF shouldn't inspect all mirrors - you would waste too much resources then. 
 We need
 a better mechanism. Just 1 reference repomd metadata with the most up-to-date 
 metadata
 checksums (on one server only). Than we could detect the mirror DNF chose is 
 outdated.
 

Stuff for everyone interested.

The feedback in the ticket I've opened is not encouraging so far.
https://fedorahosted.org/fedora-infrastructure/ticket/4866
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf --refresh reverts to older metadata (was: Re: dnf update vs Software Udpates)

[Michael Schwendt]

On Tue, 18 Aug 2015 05:54:07 -0400 (EDT), Honza Šilhan wrote:

 File a bug, if you care, please.

And if I don't file a bug, I don't care?
That would be an odd way to put it. =:-/

Would you rather prefer silence and people returning to another distribution? 
I mean, it is not clear yet whether mirror manager is the culprit, is it?

Also, it's very unlikely that the dnf developers use only bugzilla for all 
project
management, such as todo lists and milestone target details. Now that you've 
learned
there is some fundamental problem, it should be put onto some internal todo list
to schedule some proof-reading of the implementation and sit together with the
mirror manager guys. Very important would be to verify all the stuff around the
metalink XML parsing and evaluating, especially the 
age/timestamp/checksum/alternates.

Adding more helpful debug output would be an idea, too.
Certainly it should be possible to print metalink data age, which would be
much more relevant than the time of the last metadata expiration check.

 + output of these command sequence (to see which mirror is picked)
 # export LIBREPO_DEBUG=1  dnf update --assumeno
 # export LIBREPO_DEBUG=1  dnf update --assumeno --refresh
 # dnf clean metadata
 # export LIBREPO_DEBUG=1  dnf update --assumeno

This does not print which mirror is picked.

It does not print anything helpful at all.

I would expect debug information to include some details about the metalink 
server
response, the metadata checksum and the metadata age, and stuff like that.

| Librepo version: 1.7.16 with CURL_GLOBAL_ACK_EINTR support (libcurl/7.44.0 
NSS/3.19.3 Basic ECC zlib/1.2.8 libidn/1.32 libssh2/1.6.0 nghttp2/1.2.0)
| lr_download: Target: file:///etc/dnf/dnf.conf (-)
| select_next_target: Selecting mirror for: file:///etc/dnf/dnf.conf
| prepare_next_transfer: URL: file:///etc/dnf/dnf.conf
| add_librepo_xattr: Cannot set xattr user.Librepo.DownloadInProgress (fd: 5): 
Operation not supported
| lr_download: Downloading started
| check_transfer_statuses: Transfer finished: file:///etc/dnf/dnf.conf 
(Effective url: file:///etc/dnf/dnf.conf)
| Fedora - Rawhide - Developmental packages for t 1.4 MB/s |  43 MB 00:29   
 
| Adobe Systems Incorporated   23 kB/s | 1.8 kB 00:00   
 
| Last metadata expiration check performed 0:00:00 ago on Tue Aug 18 12:25:42 
2015.
| Dependencies resolved.

 Michael, have you run all these commands at one moment or after 1 day
 breaks?

That can be seen in dnf's output:
https://lists.fedoraproject.org/pipermail/users/2015-August/464144.html

Excerpt:

# dnf update
Last metadata expiration check performed 1:19:01 ago on Fri Aug 14 11:29:15 
2015.
[...]
Install   3 Packages
Upgrade  76 Packages
Remove3 Packages
[...]

# dnf update --refresh
Adobe Systems Incorporated   21 kB/s | 1.8 kB 00:00
Fedora - Rawhide - Developmental packages for t 1.5 MB/s |  43 MB 00:29
Last metadata expiration check performed 0:00:13 ago on Fri Aug 14 12:48:43 
2015.
[...]
Install   3 Packages
Upgrade  76 Packages
Remove3 Packages
[...]

# dnf update --refresh
Fedora - Rawhide - Developmental packages for t 1.4 MB/s |  43 MB 00:30
Adobe Systems Incorporated   21 kB/s | 1.8 kB 00:00
Last metadata expiration check performed 0:00:00 ago on Fri Aug 14 12:50:08 
2015.
[...]
Upgrade  50 Packages
[...]


As one can see, a bit more than a minute between those two last runs.
Then, a day later, only dnf clean metadata lead to fetching new metadata:
https://lists.fedoraproject.org/pipermail/users/2015-August/464173.html


Some hours later when I replied to another mail in the thread, I could reproduce
the --refresh reverts to old metadata problem with two runs one minute after
eachother:
https://lists.fedoraproject.org/pipermail/users/2015-August/464184.html

# dnf update --refresh
Adobe Systems Incorporated   21 kB/s | 1.8 kB 00:00
Fedora - Rawhide - Developmental packages for t 1.5 MB/s |  43 MB 00:29
Last metadata expiration check performed 0:00:11 ago on Sat Aug 15 19:21:15 
2015.
[...]
Install4 Packages
Upgrade  168 Packages
Remove 3 Packages
[...]

# dnf update --refresh
Adobe Systems Incorporated   13 kB/s | 1.8 kB 00:00
Fedora - Rawhide - Developmental packages for t 1.4 MB/s |  43 MB 00:29
Last metadata expiration check performed 0:00:39 ago on Sat Aug 15 19:22:31 
2015.
[...]
Install4 Packages
Upgrade  111 Packages
Remove 3 Packages
[...]
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf --refresh reverts to older metadata (was: Re: dnf update vs Software Udpates)

[Michael Schwendt]

 And here's proof of what can happen with just --refresh:
 
   1. dnf update
   2. dnf update --refresh
   3. dnf update --refresh
 
 The last run reverts to older metadata with only 50 updates available compared
 with earlier. Mirror manager assigning to an out-of-date mirror?

A day later, no matter how often I run dnf update --refresh, it never
gets access to the newer metadata from yesterday again. Not the 76 packages
as shown earlier in this thread, only the older 50.

So, indeed, there's something seriously wrong here, and I assume it
can only be fixed if the developers of mirror manager and dnf come
together and look into it.

After giving the dnf clean expire-cache option another try, too, and
then the hammer dnf clean metadata, there has been a fresh download
of even newer metadata compared with yesterday:

[...]
Install4 Packages
Upgrade  111 Packages
Remove 3 Packages

Total download size: 211 M
[...]

# rpm -q dnf
dnf-1.1.0-2.fc24.noarch
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf --refresh reverts to older metadata (was: Re: dnf update vs Software Udpates)

[Michael Schwendt]

On Sat, 15 Aug 2015 13:40:04 +0100, Patrick O'Callaghan wrote:

 Worth a BZ report surely?

Not from me this time. It is my understanding that there have been
multiple reports before.

A few hours have passed, and meanwhile there are even newer metadata.
However, a subsequent run of dnf update --refresh reverted to older
metadata. See bottom.

 I have no special insight into this, but often at the root of this type
 of problem there is a failure to clearly specify what each of the
 components is supposed to do, resulting in a mismatch between reality
 and expectation on either side.

Or using ambiguous terminology. I've seen that occasionally.


dnf update --refresh currently redownloads the 43 MB metadata *always*.
The manual page says:

   --refresh
  set metadata as expired before running the command

Apparently, it doesn't try to verify/confirm whether the cache matches
what the server offers. It seems to be less than clean expire-cache
and more like clean metadata.

It would need somebody with intimate knowledge of what mirror manager
supports. To tell whether the package tool can decide which metadata are
the latest. Perhaps timezones are not considered? Or why else did it
decide to download something that's older? Did mirror manage tell that
the cache metadata are not current?


Here's a fresh reproducer. First it fetched the newer metadata, then it
refreshed to something older:

# dnf update --refresh
Adobe Systems Incorporated   21 kB/s | 1.8 kB 00:00
Fedora - Rawhide - Developmental packages for t 1.5 MB/s |  43 MB 00:29
Last metadata expiration check performed 0:00:11 ago on Sat Aug 15 19:21:15 
2015.
Dependencies resolved.

 PackageArch   VersionRepository
   Size

Installing:
 kernel x86_64 4.2.0-0.rc6.git1.1.fc24rawhide  72 k
 kernel-corex86_64 4.2.0-0.rc6.git1.1.fc24rawhide  20 M
 kernel-modules x86_64 4.2.0-0.rc6.git1.1.fc24rawhide  18 M
 ncurses-compat-libsx86_64 6.0-1.20150810.fc24rawhide 305 k
Upgrading:
 NetworkManager x86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24
  rawhide 2.0 M
 NetworkManager-adslx86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24
  rawhide 110 k
 NetworkManager-bluetooth   x86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24
  rawhide 133 k
 NetworkManager-config-connectivity-fedora
x86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24
  rawhide 100 k
 NetworkManager-glibx86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24
  rawhide 366 k
 NetworkManager-libnm   x86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24
  rawhide 476 k
 NetworkManager-teamx86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24
  rawhide 112 k
 NetworkManager-wifix86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24
  rawhide 140 k
 NetworkManager-wwanx86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24
  rawhide 133 k
 PackageKit x86_64 1.0.7-3.fc24   rawhide 575 k
 PackageKit-cached-metadata x86_64 1.0.7-3.fc24   rawhide  73 M
 PackageKit-command-not-found   x86_64 1.0.7-3.fc24   rawhide  27 k
 PackageKit-glibx86_64 1.0.7-3.fc24   rawhide 131 k
 PackageKit-gstreamer-pluginx86_64 1.0.7-3.fc24   rawhide  19 k
 PackageKit-gtk3-module x86_64 1.0.7-3.fc24   rawhide  19 k
 aclx86_64 2.2.52-10.fc24 rawhide  76 k
 attr   x86_64 2.4.47-13.fc24 rawhide  64 k
 automake   noarch 1.15-5.fc24rawhide 694 k
 boost  x86_64 1.58.0-6.fc24  rawhide  43 k
 boost-atomic   x86_64 1.58.0-6.fc24  rawhide  45 k
 boost-chrono   x86_64 1.58.0-6.fc24  rawhide  52 k
 boost-containerx86_64 1.58.0-6.fc24  rawhide  66 k
 boost-context  x86_64 1.58.0-6.fc24  rawhide  58 k
 boost-coroutinex86_64 1.58.0-6.fc24

Re: dnf --refresh reverts to older metadata (was: Re: dnf update vs Software Udpates)

[Heinz Diehl]

On 15.08.2015, Michael Schwendt wrote: 

 A day later, no matter how often I run dnf update --refresh, it never
 gets access to the newer metadata from yesterday again. Not the 76 packages
 as shown earlier in this thread, only the older 50.

Jupp! It's exactly what I'm encountering since moving to F22, as shown
several times in this list.

 So, indeed, there's something seriously wrong here, and I assume it
 can only be fixed if the developers of mirror manager and dnf come
 together and look into it.

Indeed.

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf --refresh reverts to older metadata (was: Re: dnf update vs Software Udpates)

[Patrick O'Callaghan]

On Sat, 2015-08-15 at 13:21 +0200, Michael Schwendt wrote:
 So, indeed, there's something seriously wrong here, and I assume it
 can only be fixed if the developers of mirror manager and dnf come
 together and look into it.

Worth a BZ report surely?

I have no special insight into this, but often at the root of this type
of problem there is a failure to clearly specify what each of the
components is supposed to do, resulting in a mismatch between reality
and expectation on either side.

poc
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Patrick O'Callaghan]

On Fri, 2015-08-14 at 12:47 +0200, Michael Schwendt wrote:
 Behaviour of running with --refresh and after clean metadata
 (or the infamous clean all) differs, because whereas the latter 
 forces dnf to start from scratch and download all metadata, the 
 former only expires the metadata. It remains available in the cache 
 for a check whether it may still be current.

If the metadata is expired, why is it being checked for currency?

poc
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Michael Schwendt]

On Fri, 14 Aug 2015 11:59:48 +0100, Patrick O'Callaghan wrote:

 If the metadata is expired, why is it being checked for currency?

User tells the tool the metadata are expired. Whether that is true,
remains to be seen. They are still in the local cache, and the
mirroring system may tell that there are no different metadata. Then
there's no need to redownload them.

If the documentation is not accurate, and if --refresh removes the
cached metadata always, then the developers ought to make that clear.

   --refresh
  set metadata as expired before running the command

  dnf clean expire-cache
  Removes  local  cookie  files  saying when the metadata and mir‐
  rorlists were downloaded for each repo. DNF will re-validate the
  cache for each repo the next time it is used.

   dnf clean metadata
  Removes  repository metadata. Those are the files which DNF uses
  to determine the remote availability  of  packages.  Using  this
  option  will make DNF download all the metadata the next time it
  is run.

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Michael Schwendt]

On Thu, 13 Aug 2015 23:05:06 -0400, Rahul Sundaram wrote:

 Hi
 
 On Thu, Aug 13, 2015 at 3:43 PM, Andreas M. Kirchwitz wrote:
 
 
  That does clearly *not* provide the latest updates. It's better than
  without --refresh, but dnf clean metadata is required for full
  updates available.
 
 
 That contradicts the documentation provided.  I would suggest filing a bug
 report.  I would do it myself if I can reproduce that but I haven't run
 into this problem

 From my observations so far, it seems users are mistaken in at least one
case. Behaviour of running with --refresh and after clean metadata
(or the infamous clean all) differs, because whereas the latter forces
dnf to start from scratch and download all metadata, the former only
expires the metadata. It remains available in the cache for a check whether
it may still be current. A similar clean command that doesn't remove the
metadata is clean expire-cache, but unfortunately, users always compare
with clean all which removes too much in nearly all cases.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

dnf --refresh reverts to older metadata (was: Re: dnf update vs Software Udpates)

[Michael Schwendt]

And here's proof of what can happen with just --refresh:

  1. dnf update
  2. dnf update --refresh
  3. dnf update --refresh

The last run reverts to older metadata with only 50 updates available compared
with earlier. Mirror manager assigning to an out-of-date mirror?


# dnf update
Last metadata expiration check performed 1:19:01 ago on Fri Aug 14 11:29:15 
2015.
Dependencies resolved.

 Package   Arch Version Repository
   Size

Installing:
 kernelx86_64   4.2.0-0.rc6.git0.2.fc24 rawhide72 k
 kernel-core   x86_64   4.2.0-0.rc6.git0.2.fc24 rawhide20 M
 kernel-modulesx86_64   4.2.0-0.rc6.git0.2.fc24 rawhide18 M
Upgrading:
 automake  noarch   1.15-5.fc24 rawhide   694 k
 boost x86_64   1.58.0-6.fc24   rawhide43 k
 boost-atomic  x86_64   1.58.0-6.fc24   rawhide45 k
 boost-chrono  x86_64   1.58.0-6.fc24   rawhide52 k
 boost-container   x86_64   1.58.0-6.fc24   rawhide66 k
 boost-context x86_64   1.58.0-6.fc24   rawhide58 k
 boost-coroutine   x86_64   1.58.0-6.fc24   rawhide59 k
 boost-date-time   x86_64   1.58.0-6.fc24   rawhide58 k
 boost-devel   x86_64   1.58.0-6.fc24   rawhide   8.1 M
 boost-filesystem  x86_64   1.58.0-6.fc24   rawhide73 k
 boost-graph   x86_64   1.58.0-6.fc24   rawhide   137 k
 boost-iostreams   x86_64   1.58.0-6.fc24   rawhide67 k
 boost-locale  x86_64   1.58.0-6.fc24   rawhide   278 k
 boost-log x86_64   1.58.0-6.fc24   rawhide   478 k
 boost-mathx86_64   1.58.0-6.fc24   rawhide   312 k
 boost-program-options x86_64   1.58.0-6.fc24   rawhide   165 k
 boost-python  x86_64   1.58.0-6.fc24   rawhide   133 k
 boost-random  x86_64   1.58.0-6.fc24   rawhide51 k
 boost-regex   x86_64   1.58.0-6.fc24   rawhide   296 k
 boost-serialization   x86_64   1.58.0-6.fc24   rawhide   156 k
 boost-signals x86_64   1.58.0-6.fc24   rawhide70 k
 boost-system  x86_64   1.58.0-6.fc24   rawhide48 k
 boost-testx86_64   1.58.0-6.fc24   rawhide   220 k
 boost-thread  x86_64   1.58.0-6.fc24   rawhide88 k
 boost-timer   x86_64   1.58.0-6.fc24   rawhide50 k
 boost-wavex86_64   1.58.0-6.fc24   rawhide   234 k
 crontabs  noarch   1.11-11.20150630git.fc24rawhide23 k
 curl  x86_64   7.44.0-1.fc24   rawhide   284 k
 dbus  x86_64   1:1.9.20-1.fc24 rawhide   240 k
 dbus-develx86_64   1:1.9.20-1.fc24 rawhide57 k
 dbus-libs x86_64   1:1.9.20-1.fc24 rawhide   171 k
 dbus-x11  x86_64   1:1.9.20-1.fc24 rawhide51 k
 dhcp-client   x86_64   12:4.3.3-0.2b1.fc24 rawhide   297 k
 dhcp-common   noarch   12:4.3.3-0.2b1.fc24 rawhide   192 k
 dhcp-libs x86_64   12:4.3.3-0.2b1.fc24 rawhide   136 k
 dracutx86_64   043-60.git20150811.fc24 rawhide   322 k
 dracut-config-rescue  x86_64   043-60.git20150811.fc24 rawhide44 k
 dracut-networkx86_64   043-60.git20150811.fc24 rawhide82 k
 firefox   x86_64   40.0-4.fc24 rawhide71 M
 fontconfigx86_64   2.11.94-3.fc24  rawhide   241 k
 fontconfig-devel  x86_64   2.11.94-3.fc24  rawhide   136 k
 gnupg2x86_64   2.1.6-1.fc24rawhide   1.8 M
 hplip x86_64   3.15.7-4.fc24   rawhide12 M
 hplip-common  x86_64   3.15.7-4.fc24   rawhide96 k
 hplip-compat-libs x86_64   3.15.7-4.fc24   rawhide76 k
 hplip-libsx86_64   3.15.7-4.fc24   rawhide   185 k
 kernel-headersx86_64   4.2.0-0.rc6.git0.2.fc24 rawhide   1.0 M
 libblkid  x86_64   2.27-0.2.fc24   rawhide   178 k
 libcacard x86_64   2:2.4.0-1.fc24  rawhide74 k
 libcurl   x86_64   7.44.0-1.fc24   rawhide   256 k
 libcurl-devel 

Re: dnf update vs Software Udpates

[Patrick O'Callaghan]

On Thu, 2015-08-13 at 20:49 +, Andreas M. Kirchwitz wrote:
 Maybe it would be less confusing if --refresh did the job
 (which sounds like a cool workaround for that kind of problem)
 but there's a difference between --refresh and clean metadata.

From the dnf(1) man page:

Note that in all situations the user can force synchronization of
all enabled repositories with the --refresh switch.

So are you saying the documentation is wrong?

poc

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Andreas M. Kirchwitz]

Suvayu Ali fatkasuvayu+li...@gmail.com wrote:

 In practice, there's not much of a difference between clean all
 or just clean metadata. Because both require the update/upgrade
 command to download all stuff from the network and build to whole
 meta database from scratch, even if that wouldn't be necessary.

 Sorry, that's not correct.  Ever since the yum days, they have been
 different.  The key differences are these two bits (from `man dnf'):
 [...]

Sorry for any confusion I may have caused by my statement.
Of course, both are not the same, but if a user of a standard
Fedora system with no fancy configuration just wants to install
latest updates (and rarely uses dnf for anything else), then
my experience shows that there's no significant amount of cached
data that clean metadata would have preserved over clean all.

No matter if dnf clean metadata or dnf clean all is used,
the directly following dnf upgrade uses the same amount of
resources (traffic + CPU).

Yes, I agree, other commands may benefit a lot if clean metadata
is used instead of clean all. Personally, I rarely use dnf for
anything but updating the system. Maybe that's why I don't see
a difference.

But to be honest, that wasn't my point anyway. My point is that
users should not need to use either of those (clean metadata or
clean all), but there should be a way that dnf upgrade (especially
if used interactively on command-line) provides what users expect
without any fiddling with cached data.

 During the yum days, the most frequent complaint on this list were: why
 is yum so slow, I hate waiting for metadata updates,  and so on.
 And now people complain, the cached metadata is out of date (please
 don't confuse this with actual bugs).  There is no winning, you either
 wait for the metadata to download, or you get a responsive interface.

For my individual needs, I run dnf --disablerepo=fedora clean metadata
before I check for updates (actually I use a two-line script for that).
The fedora repository uses up the most resources for downloading and
rebuilding metadata. This way I still benefit from caching but also get
the freshest updates.

For all other yum/dnf operations (which I rarely use) I'm fine with
the default caching and happily use the default repo files provided
by Fedora.

 PS: I've no relation to the dnf team, just a user.  I however think
 instead of complaining on the list, if any discussions here lead you
 to think there is a problem with dnf (as in a bug), you should file
 bug reports.

Several tickets already exist for that issue, and the answer is
always the same: People should run clean metadata (or clean all
if they have plenty of resources) before they update.

Technically, that might be a proper solution, but that won't get
people from asking the very same question over and over again.

Maybe it would be less confusing if --refresh did the job
(which sounds like a cool workaround for that kind of problem)
but there's a difference between --refresh and clean metadata.
Could that be caused by metadata_expire=6h in fedora-updates.repo?

Greetings, Andreas
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Suvayu Ali]

On Thu, Aug 13, 2015 at 07:43:49PM +, Andreas M. Kirchwitz wrote:
 Rahul Sundaram methe...@gmail.com wrote:
 
  However, if somebody runs dnf upgrade on the command shell then
  he clearly wants the latest updates. Right now! No caching or other
  magic involved. That's the whole point of running dnf upgrade
  manually, otherwise the user would have left the whole updating
  business to some automated background task.
 
  If this is what you want,  use dnf update --refresh instead
 
 That does clearly *not* provide the latest updates. It's better than
 without --refresh, but dnf clean metadata is required for full
 updates available.

FWIW, this my bug report fell on deaf ears:

  https://bugzilla.redhat.com/show_bug.cgi?id=1246253

I find it disheartening how it was closed without even acknowledging
that the problem exists, so I decided not to pursue this further.  If
someone is willing to put in the effort to push for this, please reopen
the bug.  Or maybe a new one, specifically on --refresh not doing what it
is supposed to.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Andreas M. Kirchwitz]

Rahul Sundaram methe...@gmail.com wrote:

 However, if somebody runs dnf upgrade on the command shell then
 he clearly wants the latest updates. Right now! No caching or other
 magic involved. That's the whole point of running dnf upgrade
 manually, otherwise the user would have left the whole updating
 business to some automated background task.

 If this is what you want,  use dnf update --refresh instead

That does clearly *not* provide the latest updates. It's better than
without --refresh, but dnf clean metadata is required for full
updates available.

Once you figured that out, you can write a script and then get what
you want. All other users come here every couple of weeks and will
ask the same question again: Why doesn't yum/dnf fetch all updates?
And that's indeed a good question, why dnf upgrade called
interactively on a shell does such an excessive caching so that
people are wondering if it is working properly at all.

If I do ls on my shell prompt, I also expect the actual contents
of the current directory and not some cached output six hours ago. :-)

Greetings, Andreas
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Rahul Sundaram]

Hi

On Thu, Aug 13, 2015 at 3:43 PM, Andreas M. Kirchwitz wrote:


 That does clearly *not* provide the latest updates. It's better than
 without --refresh, but dnf clean metadata is required for full
 updates available.


That contradicts the documentation provided.  I would suggest filing a bug
report.  I would do it myself if I can reproduce that but I haven't run
into this problem

Rahul
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Bob Marcan]

On Fri, 7 Aug 2015 22:38:22 -0400
Rahul Sundaram methe...@gmail.com wrote:

 Hi
 
 On Fri, Aug 7, 2015 at 10:23 PM, Andreas M. Kirchwitz
 
  However, if somebody runs dnf upgrade on the command shell then
  he clearly wants the latest updates. Right now! No caching or other
  magic involved. That's the whole point of running dnf upgrade
  manually, otherwise the user would have left the whole updating
  business to some automated background task.
 
 
 If this is what you want,  use dnf update --refresh instead
 
 Rahul

Then please explain this.

[root@smicro bob]# dnf --refresh --best update
RPM Fusion for Fedora 22 - Free - Updates   249 kB/s |  29 kB 00:00
...
RPM Fusion for Fedora 22 - Nonfree  876 kB/s | 170 kB 00:00
Last metadata expiration check performed 0:00:00 ago on Sat Aug  8 09:32:41 
2015.
Dependencies resolved.
Nothing to do.
Complete!

[root@smicro bob]# dnf clean all
Cleaning repos: google-earth fedora rpmfusion-free-updates fedora-HandBrake
  : rpmfusion-nonfree-updates local adobe-linux-x86_64 updates
  : rpmfusion-free rpmfusion-nonfree
Cleaning up Everything

[root@smicro bob]# dnf --refresh --best update
Fedora 22 - x86_64  6.9 MB/s |  41 MB 00:05
RPM Fusion for Fedora 22 - Free - Updates   253 kB/s |  29 kB 00:00
...
RPM Fusion for Fedora 22 - Nonfree  891 kB/s | 170 kB 00:00
Last metadata expiration check performed 0:00:05 ago on Sat Aug  8 09:43:16 
2015.
Dependencies resolved.

 PackageArch   VersionRepository
   Size

Upgrading:
 autocorr-ennoarch 1:4.4.5.2-1.fc22   updates 176 k
 autocorr-slnoarch 1:4.4.5.2-1.fc22   updates 160 k
...
 zshx86_64 5.0.8-5.fc22   updates 2.6 M

Transaction Summary

Upgrade  48 Packages

Total download size: 203 M
Is this ok [y/N]: 

BR, Bob
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Suvayu Ali]

On Sat, Aug 08, 2015 at 02:23:34AM +, Andreas M. Kirchwitz wrote:
 Suvayu Ali fatkasuvayu+li...@gmail.com wrote:
 
  I hope this will be done *fast*, because I have to clean all
  *everytime* checking for updates. Otherwise, no updates are shown, even
  though they exist. This is a major bug.
 
  I'm sorry but clean all is not necessary at all!  clean metadata or
  clean expire-cache should be sufficient.  
 
 In practice, there's not much of a difference between clean all
 or just clean metadata. Because both require the update/upgrade
 command to download all stuff from the network and build to whole
 meta database from scratch, even if that wouldn't be necessary.

Sorry, that's not correct.  Ever since the yum days, they have been
different.  The key differences are these two bits (from `man dnf'):

  [...]
  dnf clean packages
Removes any cached packages from the system.
  
  dnf clean plugins
Tells  all enabled  plugins to  eliminate their  cached
data.
  
  dnf clean all
Does all of the above.


By removing packages, you are losing the ability to do offline
transactions.  Cleaning cached data from plugins, can do any number of
things depending on the enabled plugins.  So please stop repeating this
obviously incorrect information.

  That said, I sometimes do not understand what's the harm in getting
  updates few hours later.
 
 Caching might be cool for automated tasks (eg, cron jobs or background
 processes) and also for some actions that do not require up-to-date
 metadata.

During the yum days, the most frequent complaint on this list were: why
is yum so slow, I hate waiting for metadata updates,  and so on.
And now people complain, the cached metadata is out of date (please
don't confuse this with actual bugs).  There is no winning, you either
wait for the metadata to download, or you get a responsive interface.

PS: I've no relation to the dnf team, just a user.  I however think
instead of complaining on the list, if any discussions here lead you
to think there is a problem with dnf (as in a bug), you should file
bug reports.

-- 
Suvayu

Open source is the future. It sets us free.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Andreas M. Kirchwitz]

Suvayu Ali fatkasuvayu+li...@gmail.com wrote:

 I hope this will be done *fast*, because I have to clean all
 *everytime* checking for updates. Otherwise, no updates are shown, even
 though they exist. This is a major bug.

 I'm sorry but clean all is not necessary at all!  clean metadata or
 clean expire-cache should be sufficient.  

In practice, there's not much of a difference between clean all
or just clean metadata. Because both require the update/upgrade
command to download all stuff from the network and build to whole
meta database from scratch, even if that wouldn't be necessary.

For the typical desktop PC, clean metadata is not a time-saver
compared to clean all. Just more letters to type.

clean metadata may make sense if you add --disablerepo=fedora,
because this really saves bandwidth and CPU for the update/upgrade.

Btw, clean expire-cache (or --refresh) won't do the trick to
get the latest updates available. (However, it's still better
than just update/upgrade without anything else.)

The design of yum/dnf is somewhat flawed. I totally understand that
some caching makes sense so that metadata isn't checked, downloaded
or built for every single call to yum/dnf.

However, if somebody runs dnf upgrade on the command shell then
he clearly wants the latest updates. Right now! No caching or other
magic involved. That's the whole point of running dnf upgrade
manually, otherwise the user would have left the whole updating
business to some automated background task.

 That said, I sometimes do not understand what's the harm in getting
 updates few hours later.

Caching might be cool for automated tasks (eg, cron jobs or background
processes) and also for some actions that do not require up-to-date
metadata.

But if the user wants to download an update he should get the update.

This issue comes up for years. And there's always this debate
about clean all vs. clean metadata which in fact isn't a big
difference in the real world, and - what is much more important -
both won't solve the underlying problem, so the very same issue
comes up again and again.

Greetings, Andreas
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Rahul Sundaram]

Hi

On Fri, Aug 7, 2015 at 10:23 PM, Andreas M. Kirchwitz

 However, if somebody runs dnf upgrade on the command shell then
 he clearly wants the latest updates. Right now! No caching or other
 magic involved. That's the whole point of running dnf upgrade
 manually, otherwise the user would have left the whole updating
 business to some automated background task.


If this is what you want,  use dnf update --refresh instead

Rahul
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Ralf Corsepius]

On 07/23/2015 08:28 AM, Radek Holy wrote:



- Original Message -

From: Ralf Corsepius rc040...@freenet.de
To: users@lists.fedoraproject.org
Sent: Wednesday, July 22, 2015 6:58:49 PM
Subject: Re: dnf update vs Software Udpates

On 07/22/2015 05:41 PM, Heinz Diehl wrote:

On 22.07.2015, Suvayu Ali wrote:

I usually update weekly (or at least once within two weeks). And since
F22, I get nothing to do every time I do this


What you describe indicates you could be victim of what I conside a
massive design flaw in dnf, the dnf guys have been ignoring ever since,
because they believe to know better: When dnf encounters a broken
dependency, it doesn't tell you about it and ignores it.

Try dnf --refresh --best update

Ralf


Let's admit that you ignore us as well.


No, I do not ignore you. I am simply tired of being confronted with this 
immature and broken piece of banana software called dnf and am tired 
of permanently being confronted with what I perceive as false promises.


Ralf

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Suvayu Ali]

On Thu, Jul 23, 2015 at 02:32:19AM -0400, Radek Holy wrote:
  
  Essentially I'm suggesting to treat no connectivity as a powercycle.
  Hopefully this gives the devs some ideas.
 
 Can you please file an RFE?

Done: https://bugzilla.redhat.com/show_bug.cgi?id=1246253

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Radek Holy]

- Original Message -
 From: Rick Stevens ri...@alldigital.com
 To: Community support for Fedora users users@lists.fedoraproject.org
 Sent: Wednesday, July 22, 2015 7:52:32 PM
 Subject: Re: dnf update vs Software Udpates
 
 On 07/22/2015 10:38 AM, Maurizio Marini wrote:
  On Tue, 21 Jul 2015 20:33:27 -0400
  Matthew Miller mat...@fedoraproject.org wrote:
 
  On Wed, Jul 22, 2015 at 02:10:10AM +0200, Suvayu Ali wrote:
  I'm sorry but clean all is not necessary at all!  clean metadata or
  clean expire-cache should be sufficient.
 
  You don't even need to do that. Just use the --refresh flag -- `dnf
  --refresh upgrade`.
 
 
  dnf --refresh upgrade
  does not work for me
 
  dnf clean expire-cache
  does not work for me
 
  dnf clean metadata
  does work instaed
 
 I think that was a typo. You need:
 
   dnf --refresh update

Well, dnf update is a deprecated alias for dnf upgrade 
(http://dnf.readthedocs.org/en/latest/command_ref.html#update-command).

 Running it on my machine:
 
 [root@prophead conf]# dnf --refresh update
 RPM Fusion for Fedora 21 - Free - Updates44 kB/s | 406 kB
 00:09
 Adobe Systems Incorporated  1.2 kB/s | 1.8 kB
 00:01
 RPM Fusion for Fedora 21 - Nonfree - Updates543 kB/s | 152 kB
 00:00
 RPM Fusion for Fedora 21 - Free  17 kB/s | 508 kB
 00:29
 google-chrome77 kB/s | 3.5 kB
 00:00
 RPM Fusion for Fedora 21 - Nonfree  527 kB/s | 179 kB
 00:00
 Using metadata from Wed Jul 22 10:49:27 2015 (0:00:52 hours old)
 Dependencies resolved.
 
   Package  Arch   VersionRepository
  Size
 
 Upgrading:
   google-chrome-stable x86_64 44.0.2403.89-1 google-chrome
  46 M
 
 Transaction Summary
 
 Upgrade  1 Package
 
 Total download size: 46 M
 Is this ok [y/N]:
 
 This was on a machine that had been fully updated yesterday.
 --
 - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
 - AIM/Skype: therps2ICQ: 226437340   Yahoo: origrps2 -
 --
 -  The problem with being poor is that it takes up all of your time  -
 --
 --
 users mailing list
 users@lists.fedoraproject.org
 To unsubscribe or change subscription options:
 https://admin.fedoraproject.org/mailman/listinfo/users
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 Have a question? Ask away: http://ask.fedoraproject.org
 

-- 
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Ron Yorston]

Gordon Messmer wrote:
Use dnf repolist -v to find out, in the future.  It will print the 
date from the metadata you have, and the URL of the mirror from which it 
was retrieved.

OK, today 'dnf repolist -v' tells me:

fedora: using metadata from Wed Jul 22 08:38:59 2015.
rmy: using metadata from Wed Jul 22 08:38:59 2015.
updates: using metadata from Wed Jul 22 08:54:38 2015.
Last metadata expiration check performed 21:22:45 ago on Wed Jul 22 08:54:38 
2015.

Repo-id  : fedora
Repo-updated : Sat May 23 11:23:20 2015
Repo-expire  : 172,800 second(s) (last: Wed Jul 22 08:38:59 2015)

Repo-id  : rmy
Repo-updated : Sat Jun 20 19:40:40 2015
Repo-expire  : 172,800 second(s) (last: Wed Jul 22 08:38:59 2015)

Repo-id  : updates
Repo-updated : Tue Jul 21 06:47:56 2015
Repo-expire  : 21,600 second(s) (last: Wed Jul 22 08:54:38 2015)

The fedora and rmy repos both have the default metadata_expire of 48
hours; updates has 6 hours, as configured in fedora-updates.repo.

fedora and rmy are still within their metadata_expire timeout; updates
has expired.

Running the same commands as yesterday:

[root@vulcan rmyf22]# dnf check-update
Last metadata expiration check performed 0:00:00 ago on Thu Jul 23 06:19:10 
2015.
[root@vulcan rmyf22]# dnf --refresh check-update
Fedora 22 - x86_64 - RMY repository  78 kB/s | 6.0 kB 00:00
Last metadata expiration check performed 0:00:00 ago on Thu Jul 23 06:20:06 
2015.
[root@vulcan rmyf22]# rm -rf /var/cache/dnf/x86_64/22/updates*
[root@vulcan rmyf22]# dnf check-update
Fedora 22 - x86_64 - Updates946 kB/s |  12 MB 00:13
Last metadata expiration check performed 0:00:11 ago on Thu Jul 23 06:23:32 
2015.
[root@vulcan rmyf22]#

What immediately seems odd is that 'dnf --refresh check-update' pulled
in a new version of the rmy metadata (which hasn't expired) but not
the updates metadata (which has).

Forcibly removing the updates metadata causes a download but I get the
same version as yesterday (the one from Jul 21 06:47:56 2015) so there
are no new updates.

Actually, every time I run 'dnf --refresh check-update' the metadata for
the rmy repo is downloaded.  Maybe that's because the rmy repo has an
'ftp://' URL so dnf can't use an 'if-modified-since' request to see if
it's changed.  I wonder if that's confusing 'dnf --refresh'?

Ron
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Radek Holy]

- Original Message -
 From: Ralf Corsepius rc040...@freenet.de
 To: users@lists.fedoraproject.org
 Sent: Wednesday, July 22, 2015 6:58:49 PM
 Subject: Re: dnf update vs Software Udpates
 
 On 07/22/2015 05:41 PM, Heinz Diehl wrote:
  On 22.07.2015, Suvayu Ali wrote:
 
  I usually update weekly (or at least once within two weeks). And since
  F22, I get nothing to do every time I do this
 
 What you describe indicates you could be victim of what I conside a
 massive design flaw in dnf, the dnf guys have been ignoring ever since,
 because they believe to know better: When dnf encounters a broken
 dependency, it doesn't tell you about it and ignores it.
 
 Try dnf --refresh --best update
 
 Ralf

Let's admit that you ignore us as well.

As said many times, we are working on it [1].

First step is dnf-1.0.2.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1210445

-- 
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Radek Holy]

- Original Message -
 From: Suvayu Ali fatkasuvayu+li...@gmail.com
 To: users@lists.fedoraproject.org
 Sent: Thursday, July 23, 2015 1:07:13 AM
 Subject: Re: dnf update vs Software Udpates
 
 Hi Pete,
 
 On Wed, Jul 22, 2015 at 05:42:15PM -0500, Pete Travis wrote:
  
  There is a timer unit, `/usr/lib/systemd/system/dnf-makecache.timer`, that
  fires ten minutes after each boot then one hour following the execution of
  each previous run.  It triggers
  `/usr/lib/systemd/system/dnf-makecache.service`, a service that executes
  `dnf -v makecache timer`.  When that command runs, dnf will check the age
  of the current metadata cache and refresh it if it is older than the value
  of * metadata_timer_sync* (seconds) in `/etc/dnf/dnf.conf`.
 
 Thank you for this clear and very nice explanation.
 
  So, an always-on computer should never have metadata older than 4 hours; in
  practical terms, I think values 2 hours are increasingly unlikely.  A
  computer that's been off overnight and turned on in the morning should have
  a fresh cache within 15 minutes of boot.  If you have, say, a laptop that
  you power down often and often install or update packages immediately after
  boot, you might adjust the OnBootSec value by copying dnf-makecache.timer
  to /etc/systemd/system/ and editing accordingly.  Or, consider appending
  --refresh on an as-needed basis.
 
 I think this is where things go wrong.  OnBootSec handles powerdowns,
 what about intermittent connections?  In principle, it is quite possible
 everytime the timer triggers the makecache service, the connection is
 absent.  In fact, the probability to hit the sweet spot is directly
 determined by the reliability of the connection.  So a connection that
 is up 50% of the time, will miss 50% of the makecache jobs.  Maybe the
 makecache jobs can reset the timer to try again in 10 mins in case of no
 network connectivity.  I think that would make the odds more favourable.
 
 Essentially I'm suggesting to treat no connectivity as a powercycle.
 Hopefully this gives the devs some ideas.
 
 Cheers,
 
 --
 Suvayu

Can you please file an RFE?

Thanks
-- 
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Radek Holy]

- Original Message -
 From: Radek Holy rh...@redhat.com
 To: Community support for Fedora users users@lists.fedoraproject.org
 Sent: Thursday, July 23, 2015 9:01:24 AM
 Subject: Re: dnf update vs Software Udpates
 
 
 
 - Original Message -
  From: Ron Yorston r...@frippery.org
  To: users@lists.fedoraproject.org
  Sent: Wednesday, July 22, 2015 8:20:11 PM
  Subject: Re: dnf update vs Software Udpates
  
  Suvayu Ali wrote:
  That said, I sometimes do not understand what's the harm in getting
  updates few hours later.  dnf already tells you how old the metadata is
  when it starts, you can choose to get the latest metadata if it is too
  old.  So what's the big deal?
  
  I certainly get the impression that dnf tells me about updates less
  frequently than yum did.  It also seems to pull in metadata less
  frequently.
  
  In fedora-updates.repo I have:  metadata_expire=6h.  I also have the
  dnf-makecache.timer 'masked'.
  
  It's more than 6 hours since I last ran dnf but:
  
  [root@vulcan rmyf22]# dnf check-update
  Fedora 22 - x86_64 - RMY repository 131 kB/s | 6.0 kB 00:00
  Last metadata expiration check performed 0:00:00 ago on Wed Jul 22 08:38:32
  2015.
  [root@vulcan rmyf22]#
  
  No updates.  It pulled in metadata for my private repo but not
  fedora-updates.  So is it really telling me how old the metadata is?
  The message just refers to the last time an expiration check was
  performed.  Does that mean the metadata was up to date as of 0:00:00 ago?
  Because, as we shall see, it clearly wasn't.
 
 No, precisely, it tells you the maximum of all timestamps of caches of all
 repositories. I mean, if the cache of fedora is 3 hours old, the cache of
 updates is 2 hours old and the cache of updates-testing is 1 hour old,
 the output is 1 hour.
 
 To see all the timestamps, you should use --debug. Maybe you can help us by
 filling an RFE with a suggestion of a better message?

I mean --verbose, sorry.

  Let's try the --refresh option:
  
  [root@vulcan rmyf22]# dnf --refresh check-update
  Fedora 22 - x86_64 - RMY repository 113 kB/s | 6.0 kB 00:00
  Last metadata expiration check performed 0:00:00 ago on Wed Jul 22 08:39:01
  2015.
  [root@vulcan rmyf22]#
  
  Still no updates.  Time for a bigger hammer (don't try this at home or
  offer it as advice to newbies):
  
  [root@vulcan rmyf22]# rm -rf /var/cache/dnf/x86_64/22/updates*
  [root@vulcan rmyf22]# dnf check-update
  Fedora 22 - x86_64 - Updates774 kB/s |  12 MB 00:16
  Last metadata expiration check performed 0:00:16 ago on Wed Jul 22 08:40:02
  2015.
  
  environment-modules.x86_64 3.2.10-16.fc22
  updates
  ...
  
  Plus 55 other updates.  What's going on?
  
  Ron
  --
  users mailing list
  users@lists.fedoraproject.org
  To unsubscribe or change subscription options:
  https://admin.fedoraproject.org/mailman/listinfo/users
  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
  Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
  Have a question? Ask away: http://ask.fedoraproject.org
  
 
 --
 Radek Holý
 Associate Software Engineer
 Software Management Team
 Red Hat Czech
-- 
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Radek Holy]

- Original Message -
 From: Radek Holy rh...@redhat.com
 To: Community support for Fedora users users@lists.fedoraproject.org
 Sent: Thursday, July 23, 2015 9:01:24 AM
 Subject: Re: dnf update vs Software Udpates
 
 
 
 - Original Message -
  From: Ron Yorston r...@frippery.org
  To: users@lists.fedoraproject.org
  Sent: Wednesday, July 22, 2015 8:20:11 PM
  Subject: Re: dnf update vs Software Udpates
  
  Suvayu Ali wrote:
  That said, I sometimes do not understand what's the harm in getting
  updates few hours later.  dnf already tells you how old the metadata is
  when it starts, you can choose to get the latest metadata if it is too
  old.  So what's the big deal?
  
  I certainly get the impression that dnf tells me about updates less
  frequently than yum did.  It also seems to pull in metadata less
  frequently.
  
  In fedora-updates.repo I have:  metadata_expire=6h.  I also have the
  dnf-makecache.timer 'masked'.
  
  It's more than 6 hours since I last ran dnf but:
  
  [root@vulcan rmyf22]# dnf check-update
  Fedora 22 - x86_64 - RMY repository 131 kB/s | 6.0 kB 00:00
  Last metadata expiration check performed 0:00:00 ago on Wed Jul 22 08:38:32
  2015.
  [root@vulcan rmyf22]#
  
  No updates.  It pulled in metadata for my private repo but not
  fedora-updates.  So is it really telling me how old the metadata is?
  The message just refers to the last time an expiration check was
  performed.  Does that mean the metadata was up to date as of 0:00:00 ago?
  Because, as we shall see, it clearly wasn't.
 
 No, precisely, it tells you the maximum of all timestamps of caches of all
 repositories. I mean, if the cache of fedora is 3 hours old, the cache of
 updates is 2 hours old and the cache of updates-testing is 1 hour old,
 the output is 1 hour.

...which means that 1 hour ago, DNF found out that only updates-testing is 
expired (according to metadata_expire). I mean, there might be updates in 
another repositories as well but DNF is allowed to check it only after the 
metadata_expire period.

 To see all the timestamps, you should use --debug. Maybe you can help us by
 filling an RFE with a suggestion of a better message?
 
  Let's try the --refresh option:
  
  [root@vulcan rmyf22]# dnf --refresh check-update
  Fedora 22 - x86_64 - RMY repository 113 kB/s | 6.0 kB 00:00
  Last metadata expiration check performed 0:00:00 ago on Wed Jul 22 08:39:01
  2015.
  [root@vulcan rmyf22]#
  
  Still no updates.  Time for a bigger hammer (don't try this at home or
  offer it as advice to newbies):
  
  [root@vulcan rmyf22]# rm -rf /var/cache/dnf/x86_64/22/updates*
  [root@vulcan rmyf22]# dnf check-update
  Fedora 22 - x86_64 - Updates774 kB/s |  12 MB 00:16
  Last metadata expiration check performed 0:00:16 ago on Wed Jul 22 08:40:02
  2015.
  
  environment-modules.x86_64 3.2.10-16.fc22
  updates
  ...
  
  Plus 55 other updates.  What's going on?
  
  Ron
  --
  users mailing list
  users@lists.fedoraproject.org
  To unsubscribe or change subscription options:
  https://admin.fedoraproject.org/mailman/listinfo/users
  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
  Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
  Have a question? Ask away: http://ask.fedoraproject.org
  
 
 --
 Radek Holý
 Associate Software Engineer
 Software Management Team
 Red Hat Czech

-- 
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Ron Yorston]

Ron Yorston wrote:
What immediately seems odd is that 'dnf --refresh check-update' pulled
in a new version of the rmy metadata (which hasn't expired) but not
the updates metadata (which has).

Of course, today it didn't need to download new updates metadata
because it hadn't changed.  That wasn't the case yesterday, though.

Ron
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Radek Holy]

- Original Message -
 From: Ron Yorston r...@frippery.org
 To: users@lists.fedoraproject.org
 Sent: Wednesday, July 22, 2015 8:20:11 PM
 Subject: Re: dnf update vs Software Udpates
 
 Suvayu Ali wrote:
 That said, I sometimes do not understand what's the harm in getting
 updates few hours later.  dnf already tells you how old the metadata is
 when it starts, you can choose to get the latest metadata if it is too
 old.  So what's the big deal?
 
 I certainly get the impression that dnf tells me about updates less
 frequently than yum did.  It also seems to pull in metadata less
 frequently.
 
 In fedora-updates.repo I have:  metadata_expire=6h.  I also have the
 dnf-makecache.timer 'masked'.
 
 It's more than 6 hours since I last ran dnf but:
 
 [root@vulcan rmyf22]# dnf check-update
 Fedora 22 - x86_64 - RMY repository 131 kB/s | 6.0 kB 00:00
 Last metadata expiration check performed 0:00:00 ago on Wed Jul 22 08:38:32
 2015.
 [root@vulcan rmyf22]#
 
 No updates.  It pulled in metadata for my private repo but not
 fedora-updates.  So is it really telling me how old the metadata is?
 The message just refers to the last time an expiration check was
 performed.  Does that mean the metadata was up to date as of 0:00:00 ago?
 Because, as we shall see, it clearly wasn't.

No, precisely, it tells you the maximum of all timestamps of caches of all 
repositories. I mean, if the cache of fedora is 3 hours old, the cache of 
updates is 2 hours old and the cache of updates-testing is 1 hour old, the 
output is 1 hour.

To see all the timestamps, you should use --debug. Maybe you can help us by 
filling an RFE with a suggestion of a better message?

 Let's try the --refresh option:
 
 [root@vulcan rmyf22]# dnf --refresh check-update
 Fedora 22 - x86_64 - RMY repository 113 kB/s | 6.0 kB 00:00
 Last metadata expiration check performed 0:00:00 ago on Wed Jul 22 08:39:01
 2015.
 [root@vulcan rmyf22]#
 
 Still no updates.  Time for a bigger hammer (don't try this at home or
 offer it as advice to newbies):
 
 [root@vulcan rmyf22]# rm -rf /var/cache/dnf/x86_64/22/updates*
 [root@vulcan rmyf22]# dnf check-update
 Fedora 22 - x86_64 - Updates774 kB/s |  12 MB 00:16
 Last metadata expiration check performed 0:00:16 ago on Wed Jul 22 08:40:02
 2015.
 
 environment-modules.x86_64 3.2.10-16.fc22
 updates
 ...
 
 Plus 55 other updates.  What's going on?
 
 Ron
 --
 users mailing list
 users@lists.fedoraproject.org
 To unsubscribe or change subscription options:
 https://admin.fedoraproject.org/mailman/listinfo/users
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 Have a question? Ask away: http://ask.fedoraproject.org
 

-- 
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Ralf Corsepius]

On 07/23/2015 06:05 AM, Rahul Sundaram wrote:

Hi

On Wed, Jul 22, 2015 at 10:55 PM, dwoody5654  wrote:

Is there a way to make dnf provide info instead of being silent?

The answer was posted earlier in the thread.


Well, the real answer would be to change dnf's behaviour.

The current behaviour is just non-helpful design flaw.


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Ed Greshko]

On 07/23/15 14:30, Radek Holy wrote:
 Well, dnf update is a deprecated alias for dnf upgrade 
 (http://dnf.readthedocs.org/en/latest/command_ref.html#update-command).

At the risk of sounding pedantic, shouldn't there then be a change to 
check-upgrade and depreciate check-update.  :-)

FWIW, I'm not having any real issues with using dnf.  One just has to commit to 
the learning curve.  :-)

-- 
If I wanted a blog or social media I'd go elsewhere
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Radek Holy]

- Original Message -
 From: Ed Greshko ed.gres...@greshko.com
 To: Community support for Fedora users users@lists.fedoraproject.org
 Sent: Thursday, July 23, 2015 11:20:05 AM
 Subject: Re: dnf update vs Software Udpates
 
 On 07/23/15 14:30, Radek Holy wrote:
  Well, dnf update is a deprecated alias for dnf upgrade
  (http://dnf.readthedocs.org/en/latest/command_ref.html#update-command).
 
 At the risk of sounding pedantic, shouldn't there then be a change to
 check-upgrade and depreciate check-update.  :-)
 
 FWIW, I'm not having any real issues with using dnf.  One just has to commit
 to the learning curve.  :-)
 
 --
 If I wanted a blog or social media I'd go elsewhere

Yes, sounds reasonable :)
-- 
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Suvayu Ali]

On Wed, Jul 22, 2015 at 05:41:48PM +0200, Heinz Diehl wrote:
 On 22.07.2015, Suvayu Ali wrote: 
 
  That said, I sometimes do not understand what's the harm in getting
  updates few hours later.  dnf already tells you how old the metadata is
  when it starts, you can choose to get the latest metadata if it is too
  old.  So what's the big deal?
 
 I usually update weekly (or at least once within two weeks). And since
 F22, I get nothing to do every time I do this - although there are
 updates waiting. Which is.. annoying. So every time I have to clean
 the cache to be able to update.

This is strange.  I see very different behaviour.  I update once every 2
days or so.  Usually my metadata is a few hours old.  Here are some
examples:

On my laptop:
  # dnf check-update 
  Last metadata expiration check performed 2:01:15 ago on Wed Jul 22 15:47:25 
2015.
and I have a bunch of updates waiting.

On my home server:
  # dnf check-update 
  Last metadata expiration check performed 1:19:48 ago on Wed Jul 22 16:30:00 
2015.
with approximately similar set of updates waiting.

On an old laptop which I have not updated in some time.
  $ sudo dnf check-update
  [sudo] password for jallad:
  Last metadata expiration check performed 2:29:02 ago on Wed Jul 22 15:22:05 
2015.
a much larger set of updates awaiting.

My local time is, 2015-07-22 17:54:30.  So they are all within 2-3
hours.  That is why I find your case a bit puzzling.  Maybe it is
worthwhile to file a bugzilla.  To be complete, I have no metadata
related options set in dnf.conf or yum.conf.  Maybe you have something
like that set?

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Heinz Diehl]

On 22.07.2015, Suvayu Ali wrote: 

 I'm sorry but clean all is not necessary at all!  clean metadata or
 clean expire-cache should be sufficient.  

Ok.

 That said, I sometimes do not understand what's the harm in getting
 updates few hours later.  dnf already tells you how old the metadata is
 when it starts, you can choose to get the latest metadata if it is too
 old.  So what's the big deal?

I usually update weekly (or at least once within two weeks). And since
F22, I get nothing to do every time I do this - although there are
updates waiting. Which is.. annoying. So every time I have to clean
the cache to be able to update.

This was at least not how yum behaved. But if it's intended behaviour
now, well...

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Patrick O'Callaghan]

On Wed, 2015-07-22 at 17:41 +0200, Heinz Diehl wrote:
 On 22.07.2015, Suvayu Ali wrote: 
 
  I'm sorry but clean all is not necessary at all!  clean 
  metadata or
  clean expire-cache should be sufficient.  
 
 Ok.
 
  That said, I sometimes do not understand what's the harm in getting
  updates few hours later.  dnf already tells you how old the 
  metadata is
  when it starts, you can choose to get the latest metadata if it is 
  too
  old.  So what's the big deal?
 
 I usually update weekly (or at least once within two weeks). And 
 since
 F22, I get nothing to do every time I do this - although there are
 updates waiting. Which is.. annoying. So every time I have to clean
 the cache to be able to update.
 
 This was at least not how yum behaved. But if it's intended behaviour
 now, well...

I update every day, and most days there are some changes. I never clean
the cache. I also never use anything except dnf.

poc
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Ralf Corsepius]

On 07/22/2015 05:41 PM, Heinz Diehl wrote:

On 22.07.2015, Suvayu Ali wrote:

I usually update weekly (or at least once within two weeks). And since
F22, I get nothing to do every time I do this


What you describe indicates you could be victim of what I conside a 
massive design flaw in dnf, the dnf guys have been ignoring ever since, 
because they believe to know better: When dnf encounters a broken 
dependency, it doesn't tell you about it and ignores it.


Try dnf --refresh --best update

Ralf




--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Rick Stevens]

On 07/22/2015 10:38 AM, Maurizio Marini wrote:

On Tue, 21 Jul 2015 20:33:27 -0400
Matthew Miller mat...@fedoraproject.org wrote:


On Wed, Jul 22, 2015 at 02:10:10AM +0200, Suvayu Ali wrote:

I'm sorry but clean all is not necessary at all!  clean metadata or
clean expire-cache should be sufficient.


You don't even need to do that. Just use the --refresh flag -- `dnf
--refresh upgrade`.



dnf --refresh upgrade
does not work for me

dnf clean expire-cache
does not work for me

dnf clean metadata
does work instaed


I think that was a typo. You need:

dnf --refresh update

Running it on my machine:

[root@prophead conf]# dnf --refresh update
RPM Fusion for Fedora 21 - Free - Updates44 kB/s | 406 kB 
00:09
Adobe Systems Incorporated  1.2 kB/s | 1.8 kB 
00:01
RPM Fusion for Fedora 21 - Nonfree - Updates543 kB/s | 152 kB 
00:00
RPM Fusion for Fedora 21 - Free  17 kB/s | 508 kB 
00:29
google-chrome77 kB/s | 3.5 kB 
00:00
RPM Fusion for Fedora 21 - Nonfree  527 kB/s | 179 kB 
00:00

Using metadata from Wed Jul 22 10:49:27 2015 (0:00:52 hours old)
Dependencies resolved.

 Package  Arch   VersionRepository 
Size


Upgrading:
 google-chrome-stable x86_64 44.0.2403.89-1 google-chrome 
46 M


Transaction Summary

Upgrade  1 Package

Total download size: 46 M
Is this ok [y/N]:

This was on a machine that had been fully updated yesterday.
--
- Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
- AIM/Skype: therps2ICQ: 226437340   Yahoo: origrps2 -
--
-  The problem with being poor is that it takes up all of your time  -
--
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Matthew Miller]

On Wed, Jul 22, 2015 at 10:57:39AM -0700, Rick Stevens wrote:
 Open mouth, insert foot. While what I did did result in the chrome
 update, a dnf clean metadata;dnf update did come up with 21 more
 items to update--even though it said the metadata was 45 seconds old.

Are you sure you're not just hitting a different mirror?

-- 
Matthew Miller
mat...@fedoraproject.org
Fedora Project Leader
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Maurizio Marini]

On Tue, 21 Jul 2015 20:33:27 -0400
Matthew Miller mat...@fedoraproject.org wrote:

 On Wed, Jul 22, 2015 at 02:10:10AM +0200, Suvayu Ali wrote:
  I'm sorry but clean all is not necessary at all!  clean metadata or
  clean expire-cache should be sufficient.  
 
 You don't even need to do that. Just use the --refresh flag -- `dnf
 --refresh upgrade`.
 

dnf --refresh upgrade
does not work for me

dnf clean expire-cache
does not work for me

dnf clean metadata
does work instaed

-m


smime.p7s
Description: S/MIME cryptographic signature
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Joe Zeff]

On 07/22/2015 10:57 AM, Rick Stevens wrote:


dnf really needs some serious surgery.


I do hope that they don't drop yum (or yum-deprecated as they now call 
it) until dnf is at least as feature-complete as yum.

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Joe Zeff]

On 07/22/2015 09:58 AM, Ralf Corsepius wrote:

What you describe indicates you could be victim of what I conside a
massive design flaw in dnf, the dnf guys have been ignoring ever since,
because they believe to know better: When dnf encounters a broken
dependency, it doesn't tell you about it and ignores it.


...and this is supposed to be better than yum.  Why?
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Heinz Diehl]

On 22.07.2015, Rick Stevens wrote: 

 Open mouth, insert foot. While what I did did result in the chrome
 update, a dnf clean metadata;dnf update did come up with 21 more
 items to update--even though it said the metadata was 45 seconds old.

Welcome to the club..

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Matthew Miller]

On Wed, Jul 22, 2015 at 07:20:11PM +0100, Ron Yorston wrote:
 That said, I sometimes do not understand what's the harm in getting
 updates few hours later.  dnf already tells you how old the metadata is
 when it starts, you can choose to get the latest metadata if it is too
 old.  So what's the big deal?
 I certainly get the impression that dnf tells me about updates less
 frequently than yum did.  It also seems to pull in metadata less
 frequently.

Keep in mind that we only push updates once per day *anyway*.

Of course, if you're mixing in private repos or other rpm providers,
there may be different policies.

-- 
Matthew Miller
mat...@fedoraproject.org
Fedora Project Leader
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Rick Stevens]

On 07/22/2015 10:52 AM, Rick Stevens wrote:

On 07/22/2015 10:38 AM, Maurizio Marini wrote:

On Tue, 21 Jul 2015 20:33:27 -0400
Matthew Miller mat...@fedoraproject.org wrote:


On Wed, Jul 22, 2015 at 02:10:10AM +0200, Suvayu Ali wrote:

I'm sorry but clean all is not necessary at all!  clean metadata or
clean expire-cache should be sufficient.


You don't even need to do that. Just use the --refresh flag -- `dnf
--refresh upgrade`.



dnf --refresh upgrade
does not work for me

dnf clean expire-cache
does not work for me

dnf clean metadata
does work instaed


I think that was a typo. You need:

 dnf --refresh update

Running it on my machine:

[root@prophead conf]# dnf --refresh update
RPM Fusion for Fedora 21 - Free - Updates44 kB/s | 406 kB 00:09
Adobe Systems Incorporated  1.2 kB/s | 1.8 kB 00:01
RPM Fusion for Fedora 21 - Nonfree - Updates543 kB/s | 152 kB 00:00
RPM Fusion for Fedora 21 - Free  17 kB/s | 508 kB 00:29
google-chrome77 kB/s | 3.5 kB 00:00
RPM Fusion for Fedora 21 - Nonfree  527 kB/s | 179 kB 00:00
Using metadata from Wed Jul 22 10:49:27 2015 (0:00:52 hours old)
Dependencies resolved.


  Package  Arch   VersionRepository
Size


Upgrading:
  google-chrome-stable x86_64 44.0.2403.89-1 google-chrome
 46 M

Transaction Summary


Upgrade  1 Package

Total download size: 46 M
Is this ok [y/N]:

This was on a machine that had been fully updated yesterday.


Open mouth, insert foot. While what I did did result in the chrome
update, a dnf clean metadata;dnf update did come up with 21 more
items to update--even though it said the metadata was 45 seconds old.

dnf really needs some serious surgery.
--
- Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
- AIM/Skype: therps2ICQ: 226437340   Yahoo: origrps2 -
--
-  Death is nature's way of dropping carrier -
--
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Ron Yorston]

Suvayu Ali wrote:
That said, I sometimes do not understand what's the harm in getting
updates few hours later.  dnf already tells you how old the metadata is
when it starts, you can choose to get the latest metadata if it is too
old.  So what's the big deal?

I certainly get the impression that dnf tells me about updates less
frequently than yum did.  It also seems to pull in metadata less
frequently.

In fedora-updates.repo I have:  metadata_expire=6h.  I also have the
dnf-makecache.timer 'masked'.

It's more than 6 hours since I last ran dnf but:

[root@vulcan rmyf22]# dnf check-update
Fedora 22 - x86_64 - RMY repository 131 kB/s | 6.0 kB 00:00
Last metadata expiration check performed 0:00:00 ago on Wed Jul 22 08:38:32 
2015.
[root@vulcan rmyf22]#

No updates.  It pulled in metadata for my private repo but not
fedora-updates.  So is it really telling me how old the metadata is?
The message just refers to the last time an expiration check was
performed.  Does that mean the metadata was up to date as of 0:00:00 ago?
Because, as we shall see, it clearly wasn't.

Let's try the --refresh option:

[root@vulcan rmyf22]# dnf --refresh check-update
Fedora 22 - x86_64 - RMY repository 113 kB/s | 6.0 kB 00:00
Last metadata expiration check performed 0:00:00 ago on Wed Jul 22 08:39:01 
2015.
[root@vulcan rmyf22]#

Still no updates.  Time for a bigger hammer (don't try this at home or
offer it as advice to newbies):

[root@vulcan rmyf22]# rm -rf /var/cache/dnf/x86_64/22/updates*
[root@vulcan rmyf22]# dnf check-update
Fedora 22 - x86_64 - Updates774 kB/s |  12 MB 00:16
Last metadata expiration check performed 0:00:16 ago on Wed Jul 22 08:40:02 
2015.

environment-modules.x86_64 3.2.10-16.fc22updates
...

Plus 55 other updates.  What's going on?

Ron
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Jan Zelený]

On 21. 7. 2015 at 20:33:27, Matthew Miller wrote:
 On Wed, Jul 22, 2015 at 02:10:10AM +0200, Suvayu Ali wrote:
  I'm sorry but clean all is not necessary at all!  clean metadata or
  clean expire-cache should be sufficient.
 
 You don't even need to do that. Just use the --refresh flag -- `dnf
 --refresh upgrade`.


... and I believe setting metadata_expire = 0 in dnf.conf will do the same 
thing permanently.

Jan
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Ron Yorston]

Matthew Miller mat...@fedoraproject.org wrote:
On Wed, Jul 22, 2015 at 07:20:11PM +0100, Ron Yorston wrote:
 I certainly get the impression that dnf tells me about updates less
 frequently than yum did.  It also seems to pull in metadata less
 frequently.

Keep in mind that we only push updates once per day *anyway*.

OK, but that's independent of the client being used.  Both yum and
dnf see the same updates, but dnf doesn't seem to be as quick to
pass them on.

Of course, if you're mixing in private repos or other rpm providers,
there may be different policies.

Sure, different repos have different policies but why would that affect
Fedora updates?  The commands I quoted clearly show that there was newer
metadata that dnf ignored until I blew away the old cache.

Ron
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Ralf Corsepius]

On 07/22/2015 07:39 PM, Joe Zeff wrote:

On 07/22/2015 09:58 AM, Ralf Corsepius wrote:

What you describe indicates you could be victim of what I conside a
massive design flaw in dnf, the dnf guys have been ignoring ever since,
because they believe to know better: When dnf encounters a broken
dependency, it doesn't tell you about it and ignores it.


...and this is supposed to be better than yum.  Why?


Don't ask me. I've complained about this behavior many times, but the 
dnf folks/RH prefer not to listen and to be non-cooperational.


Ralf

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[jd1008]

On 07/22/2015 09:58 AM, Ralf Corsepius wrote:

What you describe indicates you could be victim of what I conside a
massive design flaw in dnf, the dnf guys have been ignoring ever since,
because they believe to know better: When dnf encounters a broken
dependency, it doesn't tell you about it and ignores it.


...and this is supposed to be better than yum.  Why?



Well improving what is not broken :)

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Ralf Corsepius]

On 07/22/2015 09:32 PM, Ron Yorston wrote:

Matthew Miller mat...@fedoraproject.org wrote:

On Wed, Jul 22, 2015 at 07:20:11PM +0100, Ron Yorston wrote:

I certainly get the impression that dnf tells me about updates less
frequently than yum did.  It also seems to pull in metadata less
frequently.


Keep in mind that we only push updates once per day *anyway*.


OK, but that's independent of the client being used.  Both yum and
dnf see the same updates, but dnf doesn't seem to be as quick to
pass them on.


IIRC, dnf and yum use different default intervals/timeouts.

dnf by default uses 2 days (search for metadata_expire in
man dnf.conf, while yum used 6 hours (search for metadata_expire in 
man yum.conf).



Of course, if you're mixing in private repos or other rpm providers,
there may be different policies.


Sure, different repos have different policies but why would that affect
Fedora updates?
They affect updates when package conflicts occur. The probability to 
encounter them when mixing repos is much higher.


yum complained about them and forced users to intervene manually.

dnf by default remains silent about such conflicts and doesn't update. 
This lets users believe everything was OK, while their system actually 
is partially outdated.


Ralf



--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[dwoody5654]

On 07/22/2015 09:41 PM, Ralf Corsepius wrote:

On 07/22/2015 09:32 PM, Ron Yorston wrote:

Matthew Miller mat...@fedoraproject.org wrote:

On Wed, Jul 22, 2015 at 07:20:11PM +0100, Ron Yorston wrote:

I certainly get the impression that dnf tells me about updates less
frequently than yum did.  It also seems to pull in metadata less
frequently.


Keep in mind that we only push updates once per day *anyway*.


OK, but that's independent of the client being used.  Both yum and
dnf see the same updates, but dnf doesn't seem to be as quick to
pass them on.


IIRC, dnf and yum use different default intervals/timeouts.

dnf by default uses 2 days (search for metadata_expire in
man dnf.conf, while yum used 6 hours (search for metadata_expire
in man yum.conf).


Of course, if you're mixing in private repos or other rpm providers,
there may be different policies.


Sure, different repos have different policies but why would that affect
Fedora updates?

They affect updates when package conflicts occur. The probability to
encounter them when mixing repos is much higher.

yum complained about them and forced users to intervene manually.

dnf by default remains silent about such conflicts and doesn't update.
This lets users believe everything was OK, while their system
actually is partially outdated.

Is there a way to make dnf provide info instead of being silent?

David


Ralf





--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Rahul Sundaram]

Hi

On Wed, Jul 22, 2015 at 10:55 PM, dwoody5654  wrote:

 Is there a way to make dnf provide info instead of being silent?

 The answer was posted earlier in the thread.  Use dnf update --best.
Refer to the man dnf for details.

Rahul
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Gordon Messmer]

On 07/22/2015 11:20 AM, Ron Yorston wrote:

What's going on?


Use dnf repolist -v to find out, in the future.  It will print the 
date from the metadata you have, and the URL of the mirror from which it 
was retrieved.

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Suvayu Ali]

On Wed, Jul 22, 2015 at 07:20:11PM +0100, Ron Yorston wrote:
 Suvayu Ali wrote:
 That said, I sometimes do not understand what's the harm in getting
 updates few hours later.  dnf already tells you how old the metadata is
 when it starts, you can choose to get the latest metadata if it is too
 old.  So what's the big deal?
 
 I certainly get the impression that dnf tells me about updates less
 frequently than yum did.  It also seems to pull in metadata less
 frequently.

Everyone seems to picked on this post for me, whereas missing on my
follow-up, with actual numbers:

  http://mid.gmane.org/20150722160112.gc1...@chitra.no-ip.org

 In fedora-updates.repo I have:  metadata_expire=6h.  I also have the
 dnf-makecache.timer 'masked'.

In the above post, I say I do not change any of the defaults metadata
related configs.  From what people are posting, I have the feeling dnf
relies a lot on _continuous_ network connectivity (which is true in my
case).  If that is true, if either the connection at the users end is
intermittent, or the mirrors are unreliable, the cache probably ends up
being stale more often.

Instead of bashing and complaining, I think trying to analyse why it
works for me (and maybe a few others who are quiet), and not for the
other participants in this thread, it would be a lot more helpful to the
devs.  I can't help here since it actually works for me beautifully.
Users who see a problem are the ones in a position to contribute an
effective bug report.

My 2¢, cheers,

-- 
Suvayu

Open source is the future. It sets us free.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Pete Travis]

On Wed, Jul 22, 2015 at 5:22 PM, Suvayu Ali fatkasuvayu+li...@gmail.com
wrote:

 On Wed, Jul 22, 2015 at 07:20:11PM +0100, Ron Yorston wrote:
  Suvayu Ali wrote:
  That said, I sometimes do not understand what's the harm in getting
  updates few hours later.  dnf already tells you how old the metadata is
  when it starts, you can choose to get the latest metadata if it is too
  old.  So what's the big deal?
 
  I certainly get the impression that dnf tells me about updates less
  frequently than yum did.  It also seems to pull in metadata less
  frequently.

 Everyone seems to picked on this post for me, whereas missing on my
 follow-up, with actual numbers:

   http://mid.gmane.org/20150722160112.gc1...@chitra.no-ip.org

  In fedora-updates.repo I have:  metadata_expire=6h.  I also have the
  dnf-makecache.timer 'masked'.

 In the above post, I say I do not change any of the defaults metadata
 related configs.  From what people are posting, I have the feeling dnf
 relies a lot on _continuous_ network connectivity (which is true in my
 case).  If that is true, if either the connection at the users end is
 intermittent, or the mirrors are unreliable, the cache probably ends up
 being stale more often.

 Instead of bashing and complaining, I think trying to analyse why it
 works for me (and maybe a few others who are quiet), and not for the
 other participants in this thread, it would be a lot more helpful to the
 devs.  I can't help here since it actually works for me beautifully.
 Users who see a problem are the ones in a position to contribute an
 effective bug report.

 My 2¢, cheers,

 --
 Suvayu


There is a timer unit, `/usr/lib/systemd/system/dnf-makecache.timer`, that
fires ten minutes after each boot then one hour following the execution of
each previous run.  It triggers
`/usr/lib/systemd/system/dnf-makecache.service`, a service that executes
`dnf -v makecache timer`.  When that command runs, dnf will check the age
of the current metadata cache and refresh it if it is older than the value
of * metadata_timer_sync* (seconds) in `/etc/dnf/dnf.conf`.

So, an always-on computer should never have metadata older than 4 hours; in
practical terms, I think values 2 hours are increasingly unlikely.  A
computer that's been off overnight and turned on in the morning should have
a fresh cache within 15 minutes of boot.  If you have, say, a laptop that
you power down often and often install or update packages immediately after
boot, you might adjust the OnBootSec value by copying dnf-makecache.timer
to /etc/systemd/system/ and editing accordingly.  Or, consider appending
--refresh on an as-needed basis.

-- Pete
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Suvayu Ali]

Hi Pete,

On Wed, Jul 22, 2015 at 05:42:15PM -0500, Pete Travis wrote:
 
 There is a timer unit, `/usr/lib/systemd/system/dnf-makecache.timer`, that
 fires ten minutes after each boot then one hour following the execution of
 each previous run.  It triggers
 `/usr/lib/systemd/system/dnf-makecache.service`, a service that executes
 `dnf -v makecache timer`.  When that command runs, dnf will check the age
 of the current metadata cache and refresh it if it is older than the value
 of * metadata_timer_sync* (seconds) in `/etc/dnf/dnf.conf`.

Thank you for this clear and very nice explanation.

 So, an always-on computer should never have metadata older than 4 hours; in
 practical terms, I think values 2 hours are increasingly unlikely.  A
 computer that's been off overnight and turned on in the morning should have
 a fresh cache within 15 minutes of boot.  If you have, say, a laptop that
 you power down often and often install or update packages immediately after
 boot, you might adjust the OnBootSec value by copying dnf-makecache.timer
 to /etc/systemd/system/ and editing accordingly.  Or, consider appending
 --refresh on an as-needed basis.

I think this is where things go wrong.  OnBootSec handles powerdowns,
what about intermittent connections?  In principle, it is quite possible
everytime the timer triggers the makecache service, the connection is
absent.  In fact, the probability to hit the sweet spot is directly
determined by the reliability of the connection.  So a connection that
is up 50% of the time, will miss 50% of the makecache jobs.  Maybe the
makecache jobs can reset the timer to try again in 10 mins in case of no
network connectivity.  I think that would make the odds more favourable.

Essentially I'm suggesting to treat no connectivity as a powercycle.
Hopefully this gives the devs some ideas.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Gordon Messmer]

On 07/22/2015 04:07 PM, Suvayu Ali wrote:

I think this is where things go wrong.  OnBootSec handles powerdowns,
what about intermittent connections?  In principle, it is quite possible
everytime the timer triggers the makecache service, the connection is
absent.


Which shouldn't matter.  If no connection is available, metadata won't 
get updated until you run an interactive command that forces a refresh.  
Note that if you're on battery, makecache won't run, either.  This is a 
convenience function to reduce the delay in running interactive 
commands, and nothing more.

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Pete Travis]

On Jul 22, 2015 6:52 PM, Gordon Messmer gordon.mess...@gmail.com wrote:

 On 07/22/2015 04:07 PM, Suvayu Ali wrote:

 I think this is where things go wrong.  OnBootSec handles powerdowns,
 what about intermittent connections?  In principle, it is quite possible
 everytime the timer triggers the makecache service, the connection is
 absent.


 Which shouldn't matter.  If no connection is available, metadata won't
get updated until you run an interactive command that forces a refresh.
Note that if you're on battery, makecache won't run, either.  This is a
convenience function to reduce the delay in running interactive commands,
and nothing more.
 --


Do you have references for the on-battery behavior? That's news to me.

--Pete
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Gordon Messmer]

On 07/22/2015 04:57 PM, Pete Travis wrote:


Do you have references for the on-battery behavior? That's news to me.



/usr/lib/systemd/system/dnf-makecache.service:
ExecStart=/usr/bin/dnf -v makecache timer

man dnf:
   dnf [options] makecache timer
  Like  plain  makecache but instructs DNF to be more 
resource-aware, meaning will

  not do anything if running on battery power
...
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Radek Holy]

- Original Message -
 From: Suvayu Ali fatkasuvayu+li...@gmail.com
 To: users@lists.fedoraproject.org
 Sent: Monday, July 20, 2015 10:58:05 AM
 Subject: Re: dnf update vs Software Udpates
 
 On Mon, Jul 20, 2015 at 10:36:01AM +0200, Maurizio Marini wrote:
  On Mon, 20 Jul 2015 10:01:37 +0200
  Michael Schwendt mschwe...@gmail.com wrote:
  
   On Sun, 19 Jul 2015 20:39:36 -0500, Javier Perez wrote:
   
Ok, just did a dnf clean all , and the dnf update and the updates
showed up

Weird.
   
   Just some hours before your post I had sent this:
   https://lists.fedoraproject.org/pipermail/users/2015-July/463183.html
  
  Michael is right: all we are a mass of lame
  I have shamed very much reading his answer to me; I have posted w/out RTFM
  and
  who do not RTFM should be banned like in old good irc times
 
 Unfortunately Michael, this `yum/dnf clean all' business will never go
 away.  I remember there was a time on this list, when everytime someone
 suggested that, they got corrected.  But all the people who used to do
 the correction are tired of repeating themselves, myself included.  It's
 a lost cause.
 --
 Suvayu
 
 Open source is the future. It sets us free.
 

IIUUC, this is not completely true. I believe that once both PackageKit and DNF 
are integrated with the new CAShe [1], we will *be able* to improve this 
situation [2].

[1] https://github.com/james-antill/CAShe
[2] If users/Fedora will be OK with downloading repomd.xml more often.
-- 
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Martin Cigorraga]

Suvayu, Matthew, you rock guys, thanks!

On Tue, Jul 21, 2015, 21:33 Matthew Miller mat...@fedoraproject.org wrote:

 On Wed, Jul 22, 2015 at 02:10:10AM +0200, Suvayu Ali wrote:
  I'm sorry but clean all is not necessary at all!  clean metadata or
  clean expire-cache should be sufficient.

 You don't even need to do that. Just use the --refresh flag -- `dnf
 --refresh upgrade`.

 --
 Matthew Miller
 mat...@fedoraproject.org
 Fedora Project Leader
 --
 users mailing list
 users@lists.fedoraproject.org
 To unsubscribe or change subscription options:
 https://admin.fedoraproject.org/mailman/listinfo/users
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
 Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 Have a question? Ask away: http://ask.fedoraproject.org

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Matthew Miller]

On Wed, Jul 22, 2015 at 02:10:10AM +0200, Suvayu Ali wrote:
 I'm sorry but clean all is not necessary at all!  clean metadata or
 clean expire-cache should be sufficient.  

You don't even need to do that. Just use the --refresh flag -- `dnf
--refresh upgrade`.

-- 
Matthew Miller
mat...@fedoraproject.org
Fedora Project Leader
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Heinz Diehl]

On 21.07.2015, Radek Holy wrote: 

 IIUUC, this is not completely true. I believe that once both PackageKit and 
 DNF are integrated with the new CAShe [1], we will *be able* to improve this 
 situation [2].

I hope this will be done *fast*, because I have to clean all
*everytime* checking for updates. Otherwise, no updates are shown, even
though they exist. This is a major bug.

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Suvayu Ali]

On Tue, Jul 21, 2015 at 09:36:26PM +0200, Heinz Diehl wrote:
 On 21.07.2015, Radek Holy wrote: 
 
  IIUUC, this is not completely true. I believe that once both PackageKit and 
  DNF are integrated with the new CAShe [1], we will *be able* to improve 
  this situation [2].
 
 I hope this will be done *fast*, because I have to clean all
 *everytime* checking for updates. Otherwise, no updates are shown, even
 though they exist. This is a major bug.

I'm sorry but clean all is not necessary at all!  clean metadata or
clean expire-cache should be sufficient.  

That said, I sometimes do not understand what's the harm in getting
updates few hours later.  dnf already tells you how old the metadata is
when it starts, you can choose to get the latest metadata if it is too
old.  So what's the big deal?

-- 
Suvayu

Open source is the future. It sets us free.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Jan Zelený]

On 19. 7. 2015 at 20:39:36, Javier Perez wrote:
 Ok, just did a dnf clean all , and the dnf update and the updates showed up
 
 Weird.
 
 JP
 
 On Sun, Jul 19, 2015 at 8:32 PM, Javier Perez pepeb...@gmail.com wrote:
  This is weird.
  Software Updates on the Control Panel says that there are 39 updates
  available
  But when I run dnf update it says Nothing to do. What gives?
  
  JP


IIRC the Software Updates widget does not use dnf to check for updates, 
therefore it's likely it has a different set of metadata at its disposal. As 
you figured out, cleaning the MD cache helps.

Thanks
Jan
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Suvayu Ali]

On Mon, Jul 20, 2015 at 09:00:16AM +0200, Jan Zelený wrote:
  On Sun, Jul 19, 2015 at 8:32 PM, Javier Perez pepeb...@gmail.com wrote:
   This is weird.
   Software Updates on the Control Panel says that there are 39 updates
   available
   But when I run dnf update it says Nothing to do. What gives?
 
 IIRC the Software Updates widget does not use dnf to check for updates, 
 therefore it's likely it has a different set of metadata at its disposal. As 
 you figured out, cleaning the MD cache helps.

I'm getting a bit confused lately.  How many package managers does
Fedora have these days?  IIRC, until a year or two back, it was the same
backend (yum), but many front ends (yumex, all the packagekit based
frontends for the different desktops).  Did packagekit start doing the
backend bits itself?

From your message I understand that there are at least two different
package managers, both are Official to some capacity.  For cli users
like myself, it's dnf, for gui users it's something packagekit based.

Am I mistaken?

-- 
Suvayu

Open source is the future. It sets us free.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Michael Schwendt]

On Sun, 19 Jul 2015 20:39:36 -0500, Javier Perez wrote:

 Ok, just did a dnf clean all , and the dnf update and the updates showed up
 
 Weird.

Just some hours before your post I had sent this:
https://lists.fedoraproject.org/pipermail/users/2015-July/463183.html
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Maurizio Marini]

On Mon, 20 Jul 2015 10:01:37 +0200
Michael Schwendt mschwe...@gmail.com wrote:

 On Sun, 19 Jul 2015 20:39:36 -0500, Javier Perez wrote:
 
  Ok, just did a dnf clean all , and the dnf update and the updates showed up
  
  Weird.
 
 Just some hours before your post I had sent this:
 https://lists.fedoraproject.org/pipermail/users/2015-July/463183.html

Michael is right: all we are a mass of lame
I have shamed very much reading his answer to me; I have posted w/out RTFM and
who do not RTFM should be banned like in old good irc times

-m


smime.p7s
Description: S/MIME cryptographic signature
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Jan Zelený]

On 20. 7. 2015 at 09:43:45, Suvayu Ali wrote:
 On Mon, Jul 20, 2015 at 09:00:16AM +0200, Jan Zelený wrote:
   On Sun, Jul 19, 2015 at 8:32 PM, Javier Perez pepeb...@gmail.com 
wrote:
This is weird.
Software Updates on the Control Panel says that there are 39 updates
available
But when I run dnf update it says Nothing to do. What gives?
  
  IIRC the Software Updates widget does not use dnf to check for updates,
  therefore it's likely it has a different set of metadata at its disposal.
  As you figured out, cleaning the MD cache helps.
 
 I'm getting a bit confused lately.  How many package managers does
 Fedora have these days?  IIRC, until a year or two back, it was the same
 backend (yum), but many front ends (yumex, all the packagekit based
 frontends for the different desktops).  Did packagekit start doing the
 backend bits itself?
 
 From your message I understand that there are at least two different
 package managers, both are Official to some capacity.  For cli users
 like myself, it's dnf, for gui users it's something packagekit based.
 
 Am I mistaken?

You are not, that's pretty much it. We have had two independent software 
management stacks since F21 where PackageKit (PK) switched from yum backend to 
libhif.

At the moment PK and dnf share libraries for depsolving and downloading stuff 
but other than that the code is independent. IIRC the reason is that dnf is 
written in Python and that is not acceptable for PackageKit because of the new 
Gnome Software front end. It is likely that PK and dnf will share more code in 
the future but that's more of a very long term plan.

Thanks
Jan
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Suvayu Ali]

On Mon, Jul 20, 2015 at 10:36:01AM +0200, Maurizio Marini wrote:
 On Mon, 20 Jul 2015 10:01:37 +0200
 Michael Schwendt mschwe...@gmail.com wrote:
 
  On Sun, 19 Jul 2015 20:39:36 -0500, Javier Perez wrote:
  
   Ok, just did a dnf clean all , and the dnf update and the updates showed 
   up
   
   Weird.
  
  Just some hours before your post I had sent this:
  https://lists.fedoraproject.org/pipermail/users/2015-July/463183.html
 
 Michael is right: all we are a mass of lame
 I have shamed very much reading his answer to me; I have posted w/out RTFM and
 who do not RTFM should be banned like in old good irc times

Unfortunately Michael, this `yum/dnf clean all' business will never go
away.  I remember there was a time on this list, when everytime someone
suggested that, they got corrected.  But all the people who used to do
the correction are tired of repeating themselves, myself included.  It's
a lost cause.

-- 
Suvayu

Open source is the future. It sets us free.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Suvayu Ali]

On Mon, Jul 20, 2015 at 10:44:52AM +0200, Jan Zelený wrote:
 On 20. 7. 2015 at 09:43:45, Suvayu Ali wrote:
  On Mon, Jul 20, 2015 at 09:00:16AM +0200, Jan Zelený wrote:
On Sun, Jul 19, 2015 at 8:32 PM, Javier Perez pepeb...@gmail.com 
 wrote:
 This is weird.
 Software Updates on the Control Panel says that there are 39 updates
 available
 But when I run dnf update it says Nothing to do. What gives?
   
   IIRC the Software Updates widget does not use dnf to check for updates,
   therefore it's likely it has a different set of metadata at its disposal.
   As you figured out, cleaning the MD cache helps.
  
  I'm getting a bit confused lately.  How many package managers does
  Fedora have these days?  IIRC, until a year or two back, it was the same
  backend (yum), but many front ends (yumex, all the packagekit based
  frontends for the different desktops).  Did packagekit start doing the
  backend bits itself?
  
  From your message I understand that there are at least two different
  package managers, both are Official to some capacity.  For cli users
  like myself, it's dnf, for gui users it's something packagekit based.
  
  Am I mistaken?
 
 You are not, that's pretty much it. We have had two independent software 
 management stacks since F21 where PackageKit (PK) switched from yum backend 
 to 
 libhif.
 
 At the moment PK and dnf share libraries for depsolving and downloading stuff 
 but other than that the code is independent. IIRC the reason is that dnf is 
 written in Python and that is not acceptable for PackageKit because of the 
 new 
 Gnome Software front end. It is likely that PK and dnf will share more code 
 in 
 the future but that's more of a very long term plan.

It seems a bit strange when frontends can dictate backend requirements.
Also seems like a lot of duplicated effort, increased chances of bugs,
and what not.

Anyway, thanks for your confirmation.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: dnf update vs Software Udpates

[Javier Perez]

Ok, just did a dnf clean all , and the dnf update and the updates showed up

Weird.

JP

On Sun, Jul 19, 2015 at 8:32 PM, Javier Perez pepeb...@gmail.com wrote:

 This is weird.
 Software Updates on the Control Panel says that there are 39 updates
 available
 But when I run dnf update it says Nothing to do. What gives?

 JP

 --
 --
  /\_/\
  |O O|  pepeb...@gmail.com
   Javier Perez
    While the night runs
    toward the day...
   m m   Pepebuho watches
 from his high perch.




-- 
--
 /\_/\
 |O O|  pepeb...@gmail.com
  Javier Perez
   While the night runs
   toward the day...
  m m   Pepebuho watches
from his high perch.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org