Hide Forgot
Often, fedora rpms age out from the main yum repos / mirrors as they get updated, but nevertheless users may want to download them. For example, they may need to revert to an earlier version, or download debuginfo for it. Right now, this appears to require a user to manually search koji for any leftover build artifacts, and download by hand, one URL at a time. It would be nice if dnf/yum were willing to automate this. Not necessarily to provide full dependency searching, but e.g. given yum install kernel-4.2.3-SOMETHINGOLD, it should try to find that on koji if it can't in the configured repos.
Have you tried koji CLI? I think it works fine for your request. e.g. If I am knowing complete n-v-r of a build then I can download that build as [parag@f24 Downloads]$ koji download-build kernel-4.6.0-0.rc1.git0.3.fc25 kernel-headers-4.6.0-0.rc1.git0.3.fc25.i686.rpm | 2.1 MB 00:03 !!! kernel-PAE-devel-4.6.0-0.rc1.git0.3.fc25.i686.rpm | 21 MB 00:30 !!! kernel-tools-libs-4.6.0-0.rc1.git0.3.fc25.i686.rpm | 153 kB 00:01 !!! kernel-debug-4.6.0-0.rc1.git0.3.fc25.i686.rpm | 138 kB 00:00 !!! kernel-PAE-modules-extra-4.6.0-0.rc1.git0.3.fc25.i686.rpm | 4.3 MB 00:07 !!! kernel-devel-4.6.0-0.rc1.git0.3.fc25.i686.rpm | 21 MB 00:19 !!! kernel-debug-modules-4.6.0-0.rc1.git0.3.fc25.i686.rpm | 41 MB 00:29 !!! kernel-PAE-4.6.0-0.rc1.git0.3.fc25.i686.rpm | 138 kB 00:01 !!! kernel-PAEdebug-modules-4.6.0-0.rc1.git0.3.fc25.i686.rpm | 41 MB 00:50 !!! kernel-core-4.6.0-0.rc1.git0.3.fc25.i686.rpm | 36 MB 00:23 !!! .... <snip>
Thanks for that reference. It would be useful to have a dnf interface to it still - for familiarity and for indirect use via something like # debuginfo-install.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
I am really sorry but from my point it would be nice staff to have, but request is on incorrect place. What you need that koji will provide a repo with all packages or Fedora infrastructure will provide not only latest package in update repo. I will try to redirect the request on another component.
IMHO the metadata for big repo with all koji pkgs will be so huge that it will cause a lot of stress for koji to just provide this to all dnf users. AFAIK dnf only supports downloading static files for repos and figuring out the required packages from the static files. But for koji it would need to be some kind of smart backend where dnf would let the remote system to the translation from the user input to the set of required packages. Providing all packages directly via the mirrors is also unrealistic because of the size of all packages.
Yes, there is no possible way for Koji to provide a global yum repo. I suspect that what the requester wants is something like this.... Suppose we have the command from the original description and suppose this hypothetical plugin is enabled and configured. $ dnf install kernel-4.2.3-SOMETHINGOLD After dnf determines that the configured repos hold no such package, it would 1) see if Koji has that specific package 2) if so, download and attempt to install it, only resolving deps from the actual configured repos None of that requires Koji to generate a global repo. Granted, deps could easily break here, but I think this is somewhat of a niche use. Also, it's only a fallback handler for an error condition anyway.
> I suspect that what the requester wants is something like this.... > [...] Yup, pretty much! > 2) if so, download and attempt to install it, only resolving deps from the > actual configured repos [...] One could imagine a hack whereby a mini-repo for that particular koji build is available, and so deps from the same build could be auto-downloaded in one operation. That mini-repo could be koji-built or even dnf-plugin-built on the client side.
I really understand that requested feature will be cool for Fedora users but here is a list why we cannot provide that functionality: The requested feature cannot be a plugin: 1. It will requires deep redesign directly in dnf.Base(). There is already PR that provide such redesign (https://github.com/rpm-software-management/dnf/pull/749), but in this case to enable disabled repository when no match for argument in enabled repository. But it is only a preview. 2. We cannot redesign core of DNF for specific Fedora request due to that DNF will be not only deployed to Fedora. 3. Requested approach is not working solution or at least not nice solution because there will be uncovered requires of downloaded package from koji. Providing a solution that already has an issue in design is really something that has to be not followed. I am really sorry but there is no other option from DNF site.