Hide Forgot
Description of problem: If I want to install a package named "foobar" it is pretty simple using dnf.base.Base.install('foobar') to add it to current Hawkey.Goal object. But if I allready have a package object for the "foobar" package it not possible with public api. I could use dnf.base.Base._goal.install(po), but the it is not public api the dnf.transaction.Transaction.add_install() is not very useful, because it is first defined after the depsolve. Possible solutions - make the current Hawkey.Goal available - add a install(po=package_object) option to Base.instal(), upgrade(), etc The use-case in a package gui like yumex, the user select a number of packages and the actions to perform on them. so we know the exact package object and the action to perform, so we just want to fill up the Hawkey.Goal and the depsolve, download, run transaction Version-Release number of selected component (if applicable): 0.4.17
Indeed, we need to enable this, thanks for the report.
I would be careful with making Base._goal public. If we did, I would rewrite Base.install (and friends) to just return packages (instead of modifying the goal object), because it then might become not clear whether an API user should use Base.install or Base.goal.install. On the other hand, I would appreciate possibility to query the content of the goal. I also did not like the Yum's approach of using keyword arguments in Base.install where in fact, it wasn't possible to use both arguments at once. I would prefer two different methods.
(In reply to Radek Holy from comment #2) > I would be careful with making Base._goal public. If we did, I would rewrite > Base.install (and friends) to just return packages (instead of modifying the > goal object), Also it would need to return selectors. > because it then might become not clear whether an API user > should use Base.install or Base.goal.install. On the other hand, I would > appreciate possibility to query the content of the goal. > > I also did not like the Yum's approach of using keyword arguments in > Base.install where in fact, it wasn't possible to use both arguments at > once. I would prefer two different methods. The fact is it's tricky. We don't want to end up with what Yum had in YumBase.install() for arguments, that's for sure.
(In reply to Radek Holy from comment #2) > I would be careful with making Base._goal public. If we did, I would rewrite > Base.install (and friends) to just return packages (instead of modifying the > goal object), because it then might become not clear whether an API user > should use Base.install or Base.goal.install. On the other hand, I would > appreciate possibility to query the content of the goal. > > I also did not like the Yum's approach of using keyword arguments in > Base.install where in fact, it wasn't possible to use both arguments at > once. I would prefer two different methods. What about extending install(pkgspec) (and friend) to check if pkgspec is a string or a pkg object.
Alternatively, it would be sufficient to expose 'reponame' argument of install() et. al.
For the record, I had two ideas: 1) a possibility to inject own instance of the goal (then both sets of methods will be available) 2) change the argument of Base methods to a Query/Selector type, which provides much more possibilities to specify a package (however, it won't help Tim with his use case)
(In reply to Ales Kozumplik from comment #5) > Alternatively, it would be sufficient to expose 'reponame' argument of > install() et. al. po = some package obj base.install(str(po),reponame=po.reponame) could be a workaround for my use case
(In reply to Radek Holy from comment #6) > For the record, I had two ideas: > > 1) a possibility to inject own instance of the goal (then both sets of > methods will be available) > Could be a way to go > 2) change the argument of Base methods to a Query/Selector type, which > provides much more possibilities to specify a package (however, it won't > help Tim with his use case) This will make the use of the API more complex, I like the possibility to do simple actions like bas.install('foobar') or base.install('foobar.x86_64')
Or add a possibility to specify a repo via the pkg_spec.
(In reply to Radek Holy from comment #9) > Or add a possibility to specify a repo via the pkg_spec. pkgspec = 'spring-88.0-2.fc17.x86_64@updates' base.install(pkgspec) when we are talking about it what about local file .rpm file support currently the Base.*_local methods is not public api
Another related issue. dnf.Base.goal_parameters should be public api without setting dnf.Base.goal_parameters.allow_uninstall = True then remove is kind of useless, because you can't remove a package, something else is depending on. Example https://github.com/timlau/dnf-apiex/blob/master/dnf-remove.py try without self.goal_parameters.allow_uninstall = True and it will fail
After getting a little futher with my implemention, I will sum it up: 1. the current install, upgrade ... API will solve my need, if the reponame parameter is made public API.[1] 2. install_local is needed as public API, to support installation of local .rpm [1] 3. need to read the dnf.Base._goal object to get the content of the Hawkay.Goal. This would be enough for my usecase [1] : https://github.com/timlau/dnf-daemon/blob/master/dnfdaemon/dnfdaemon-system.py#L537 [2] : https://github.com/timlau/dnf-daemon/blob/master/dnfdaemon/dnfdaemon-system.py#L1012
3. need to read the dnf.Base._goal object to get the content of the Hawkay.Goal. is not needed anyway, have to call resolve() for be able to read the result from the Goal object and then the transaction will be populated anyway, so I can get the results from the transaction. So the list is down to: 1. the current install, upgrade ... API will solve my need, if the reponame parameter is made public API 2. install_local is needed as public API, to support installation of local .rpm and dnf.Base.goal_parameters (comment 11)
Updated the title of the report, to match the outstanding issues
Looks like most of my usecase is fixed upstream https://github.com/akozumpl/dnf/commit/64bd3c27fe2e8b946794beab59f3a7f2c3f9dd66 The only outstanding issue is dnf.Base.goal_parameters.allow_uninstall = True is need to remove packages with deps. maybe it should be True by default
Thanks for the quick feedback Tim, updated the bugzilla title.
Fulfilled by 162d881, the clients can now tell Base.resolve() via a parameter whether they want to allow the solver to remove packages: base.resolve(allow_erasing=True)
Nice, Thanks
dnf-0.5.1-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/dnf-0.5.1-1.fc20
Package dnf-0.5.1-1.fc20, hawkey-0.4.14-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-0.5.1-1.fc20 hawkey-0.4.14-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-5937/hawkey-0.4.14-1.fc20,dnf-0.5.1-1.fc20 then log in and leave karma (feedback).
dnf-plugins-core-0.0.8-2.fc20, libsolv-0.6.1-1.git6d968f1.fc20, hawkey-0.4.16-1.fc20, dnf-0.5.2-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/libsolv-0.6.1-1.git6d968f1.fc20,hawkey-0.4.16-1.fc20,dnf-0.5.2-1.fc20,dnf-plugins-core-0.0.8-2.fc20
Package dnf-plugins-core-0.0.8-2.fc20, libsolv-0.6.1-1.git6d968f1.fc20, hawkey-0.4.16-1.fc20, dnf-0.5.2-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.8-2.fc20 libsolv-0.6.1-1.git6d968f1.fc20 hawkey-0.4.16-1.fc20 dnf-0.5.2-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-6789/libsolv-0.6.1-1.git6d968f1.fc20,hawkey-0.4.16-1.fc20,dnf-0.5.2-1.fc20,dnf-plugins-core-0.0.8-2.fc20 then log in and leave karma (feedback).
dnf-plugins-core-0.0.8-2.fc20, libsolv-0.6.1-1.git6d968f1.fc20, hawkey-0.4.16-1.fc20, dnf-0.5.2-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.