Bug 905697

Radek please take a look at this. The original yum-builddep resides in yum-utils and so the 'dnf builddep' should be a plugin.

Yes, yum-builddep is needed. That said, the semantics  are not that clear: there are subtle differences when operating on a package, a srpm or a spec file. Panu sorted this out somewhere on 2013 #fedora-devel archives...

For the record, one thing I would love to see for DNF's equivalent of yum-builddep is that it accepts multiple packages as arguments, and fetches the dependencies for the whole.

With YUM, you would get different results and had to run builddep for package you want, individually.

Fixed upstream by 2d3dc76.

from http://koji.fedoraproject.org/koji/rpminfo?rpmID=4793860 build, I see that 0.0.3 version is already built in koji but this build does not provided builddep.py plugin.

dnf-plugins-core-0.0.4-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/dnf-plugins-core-0.0.4-1.fc20

[mimox ]$ rpm -q dnf-plugins-core
dnf-plugins-core-0.0.4-1.fc20.noarch
[mimox ]$ dnf builddep test
No such command: builddep. Please use /usr/bin/dnf --help

Still not working or do we need to enable the plugin somehow?

The specfile missed the install command for builddep.py plugin. This package need to be built again with builddep.py installation.

Another observation, there are now 7 plugins (python files) available in upstream source archive but only 3 plugins are getting installed in the current spec file. Good to package all the plugins.

dnf-plugins-core-0.0.5-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/dnf-plugins-core-0.0.5-1.fc20

(In reply to Parag from comment #8)
> The specfile missed the install command for builddep.py plugin. This package
> need to be built again with builddep.py installation.

Indeed, should be fine now: https://admin.fedoraproject.org/updates/dnf-plugins-core-0.0.5-1.fc20

dnf-plugins-core-0.0.5-2.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/dnf-plugins-core-0.0.5-2.fc20

One more time: https://admin.fedoraproject.org/updates/dnf-plugins-core-0.0.5-2.fc20

The remaining files are missing out from the Fedora RPM on purpose.

Thanks Ales.

Package dnf-plugins-core-0.0.4-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dnf-plugins-core-0.0.4-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-3147/dnf-plugins-core-0.0.4-1.fc20
then log in and leave karma (feedback).

dnf-plugins-core-0.0.4-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

dnf-plugins-core-0.0.6-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/dnf-plugins-core-0.0.6-1.fc20

dnf-plugins-core-0.0.6-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

I gave this a try today, by installing the dnf-plugins-core 0.8 package from F20, and then:

    # dnf builddep baobab
    Error : Failed to open: 'baobab', not a valid spec file.


That doesn't cut it. In YUM, you could just give it a package name and it would figure out the rest for you. We should expect the same level of quality from DNF: you should be able to say "dnf builddep baobab nautilus gnonlin" and have it automatically figure out all the build dependencies for all those packages.

The problem with "yum builddep foo" is that it is not reliable because of the way repositories are set up, it only really works for packages with no (arch-)conditional buildrequires and there are a *lot* of those around.

dnf builddep could of course technically do what yum builddep does, but the entirely repository based mode was left intentionally out, because its broken and unfixable.

I don't particularly understand the rationale completely but if the differences are documented, that would help.  Thanks

Buildrequires can only be reliably be acquired by
a) parsing the spec
b) looking at requires of an src.rpm built on an identical system (same arch, same installed packages, same config etc)

Fedora's source repositories are not per arch, instead the src.rpm is picked from a more or less random arch during build. This means conditions for b) are not covered. Or rather, sometimes they are, sometimes they're not. In other words, unreliable.

So from dnf perspective the choice is between explaining why the yum-builddep repodata-only feature is not implemented and why builddep arbitrarily gets it wrong :)

What dnf builddep *could* do to automate this is automatically download the src.rpm and unpack the spec for parsing the buildreqs, but that's best left for rpm >= 4.12 where there is an api for accessing the package payload.

Please see bug 1074585.