Bug 1066867

Valid thing, we'll see what we can do.

reassigning to rawhide, because it's feature and we don't want to forget about it when F20 will be EOLed

So, it turned out that changelogs are stored in metadata that are not downloaded by DNF by default. And we probably don't want to change this because they have few megabytes and DNF doesn't need them (so far). So, I hate to say it but we are not going to implement this feature in the foreseeable future unless it turns out that DNF needs the data.

So, take it as postponed for now. I'm afraid that it means that you have to download and parse the XML by yourself in the meantime if you need changelogs.

FTR, when the time of the implementation comes... We are thinking about adding a parameter to `Base.fill_sack` and an attribute to `Cli.demands` to let it download the data on demand. However there might be a problem once DNF downloads the metadata, what should happen in the next run. Should it remove the data because they might be old? Or how it will affect the mechanism of determining the age of the cache. And also, if the changelog will be available through a dnf.Package attribute, what should happen if the data are not available.

Is there a way to split out the changelogs in the metadata? Best would be to only download the relevant changes (from version X -> Y) rather than all changes.

I'm not aware of such thing. They are stored in a single XML file (see e.g. the *-other.xml.gz file in http://download.fedoraproject.org/pub/fedora/linux/releases/21/Everything/x86_64/os/repodata). After the change in bug 850896, the situation may be better but I'm afraid that still there might be people that would complain about downloading unnecessary data.

> I'm afraid that still there might be people that would complain about >downloading unnecessary data.

That is rather overcautious.
If changelog were an option, as it was in yum, such complaints would not arise.

other metadata was not download by default in yum, it was optional, It would be nice if an API user could request it.

dnf cli should not download it by default, but API and plugin should be able to request it to be downloaded

This also manifests as a missing feature (vs. yum) in repoquery. I use 'repoquery --changelog (package)' quite often; 'dnf repoquery --changelog (package)' does not work.

Adam, could you please file a bug if you miss the feature? I believe that it can be implemented also without any support in DNF (as mentioned above) since it seems that librepo is able to download the file and createrepo_c is able to parse it.

(In reply to Radek Holy from comment #9)
> Adam, could you please file a bug if you miss the feature? I believe that it
> can be implemented also without any support in DNF (as mentioned above)
> since it seems that librepo is able to download the file and createrepo_c is
> able to parse it.

Sounds a little strange if a dnf plugin like repoquery, should use librepo directly to download a metadata file and parse it.
I would be much more nice, if there was a more highlevel api in dnf or hawkey to enable it and get them by pkg.changelog like you can with yum.

we should implement this along with bug 968006 once hawkey is integrated with librepo in libhif

hawkey has been merged into libhif now, so is this something that can be implemented now?

*** Bug 1299173 has been marked as a duplicate of this bug. ***

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Any update on this one? Just today's run of "dnf update" presented me with:

 [...]
 Upgrade  51 Packages
 Total download size: 183 M
 Is this ok [y/N]: y

How can I decide if it would be "OK" to continue w/o having read through the changelogs? Yes, there's the package-announce list, but searching for 51 package update emails on the list archive can be very time consuming. Having dnf to display the changelogs would be much better.

Something like yum-plugin-changelog[0] would do, but I like the apt-listchanges[1] solution even better:


===================================
  # apt-get dist-upgrade
  The following packages will be upgraded:
    hdparm (9.51+ds-1 => 9.53+ds-1)
    [...]
  26 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
  Need to get 36.5 MB of archives.
  After this operation, 37.9 kB of additional disk space will be used.
  Do you want to continue? [Y/n] y
  
  [...downloading packages, and changelogs, and $PAGER opens...]
   
  apt-listchanges: Changelogs
  ---------------------------
  --- Changes for hdparm ---
  hdparm (9.53+ds-1) unstable; urgency=medium
  
   * New upstream version 9.53+ds
   * Update d/watch, version 4, use substitutions for package,
     version and extensions
   * Add -R option to d/hdparm-functions and hdparm.conf, Closes: #722426
   [...]
   
   [...press q to exit the pager...]
   apt-listchanges: Do you want to continue? [Y/n]
===================================


Please? :-)


[0] http://yum.baseurl.org/gitweb?p=yum-utils.git;a=tree;f=plugins/changelog
[1] https://tracker.debian.org/pkg/apt-listchanges

PR https://github.com/rpm-software-management/libdnf/pull/521

libdnf-0.22.3-1.fc29 dnf-4.0.9-1.fc29 dnf-plugins-core-4.0.2-1.fc29 dnf-plugins-extras-4.0.0-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-17cbc3c616

dnf-4.0.9-1.fc29, dnf-plugins-core-4.0.2-1.fc29, dnf-plugins-extras-4.0.0-1.fc29, libdnf-0.22.3-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-17cbc3c616

dnf-4.0.9-1.fc29, dnf-plugins-core-4.0.2-1.fc29, dnf-plugins-extras-4.0.0-1.fc29, libdnf-0.22.3-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.