Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1073859 - [api][rfe] access to dnf.Base.goal_parameters.allow_uninstall
Summary: [api][rfe] access to dnf.Base.goal_parameters.allow_uninstall
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1066869
TreeView+ depends on / blocked
 
Reported: 2014-03-07 11:08 UTC by Tim Lauridsen
Modified: 2014-05-31 23:58 UTC (History)
4 users (show)

Fixed In Version: dnf-plugins-core-0.0.8-2.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-05-31 23:58:44 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Tim Lauridsen 2014-03-07 11:08:44 UTC 
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
Comment 1 Ales Kozumplik 2014-03-07 12:58:38 UTC 
Indeed, we need to enable this, thanks for the report.
Comment 2 Radek Holy 2014-03-07 13:17:15 UTC 
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.
Comment 3 Ales Kozumplik 2014-03-07 13:20:10 UTC 
(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.
Comment 4 Tim Lauridsen 2014-03-07 13:23:31 UTC 
(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.
Comment 5 Ales Kozumplik 2014-03-07 13:25:34 UTC 
Alternatively, it would be sufficient to expose 'reponame' argument of install() et. al.
Comment 6 Radek Holy 2014-03-07 13:37:49 UTC 
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)
Comment 7 Tim Lauridsen 2014-03-07 13:39:44 UTC 
(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
Comment 8 Tim Lauridsen 2014-03-07 13:45:24 UTC 
(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')
Comment 9 Radek Holy 2014-03-07 13:58:38 UTC 
Or add a possibility to specify a repo via the pkg_spec.
Comment 10 Tim Lauridsen 2014-03-07 14:49:47 UTC 
(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
Comment 11 Tim Lauridsen 2014-03-12 11:41:24 UTC 
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
Comment 12 Tim Lauridsen 2014-03-15 07:34:09 UTC 
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
Comment 13 Tim Lauridsen 2014-03-15 15:40:48 UTC 
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)
Comment 14 Tim Lauridsen 2014-03-21 18:43:48 UTC 
Updated the title of the report, to match the outstanding issues
Comment 15 Tim Lauridsen 2014-03-28 13:16:18 UTC 
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
Comment 16 Ales Kozumplik 2014-03-28 14:24:58 UTC 
Thanks for the quick feedback Tim, updated the bugzilla title.
Comment 17 Ales Kozumplik 2014-04-03 14:07:53 UTC 
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)
Comment 18 Tim Lauridsen 2014-04-03 15:23:01 UTC 
Nice, Thanks
Comment 19 Fedora Update System 2014-05-02 08:32:21 UTC 
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
Comment 20 Fedora Update System 2014-05-02 21:04:54 UTC 
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).
Comment 21 Fedora Update System 2014-05-28 12:10:12 UTC 
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
Comment 22 Fedora Update System 2014-05-28 23:50:10 UTC 
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).
Comment 23 Fedora Update System 2014-05-31 23:58:44 UTC 
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.
Note You need to log in before you can comment on or make changes to this bug.