Bug 1227949
| Summary: | RFE: yumdb equivalent for dnf | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ali Akcaagac <aliakc> |
| Component: | dnf | Assignee: | Packaging Maintenance Team <packaging-team-maint> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 22 | CC: | aliakc, alikins, havner, jsilhan, lantw44, mluscon, packaging-team-maint, pnemade, rholy, tim.lauridsen, vmukhame |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-07-24 11:25:17 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Can you please elaborate on the work flow? It's hard to imagine why would one need to do this and thus why should DNF need to support this. I've always wondered about the use cases of the "yumdb" command. Thanks for the quick response. I am instructed to *not* get into details of our work flows (as I did previously) because of the conflicting interests (in services, systems integration and so on). All I can tell is, that we need to read and store specific informations from and in the yumdb. Above is just a small part of what we do after the cleanup process. Removing individual keys, adjusting the uuid and install owner. We also need to read checksums and being able to modify attributes. This is an critical part of our tasks which we could handle easily with yum. There was a reason for the existence of yum-utils and the possibility to alter the yumdb with 3rd party requirements otherwise the entire yum-utils package wouldn't have made sense. Right now we are in quite some *deep* (shit: to use this word) trouble because of the situation as it is. Deprecation of yum/yum-utils and dnf only supporting a subset of the requirements we urgently depend on. Some stuff can be solved easily (as we had our conversations: and thanks for the help) but others *not*. I wouldn't be that noisy if yum/yum-utils wasen't marked deprecated (and spits out deprecation messages everywhere). Unfortunately we feel quite trapped with an irritating experience here. I can give you a use case that was in my desktop workflow. I install package A. Then I install package B. After a while I decide I don't need/use package A anymore so I try to uninstall it. But then I see that package A is in B's dependencies (it tries to uninstall B with A). So I use yumdb to mark A as "reason dep" instead of "reason user" so when I stop using package B it will be enough to uninstall B and do autoremove without having to remember about A. Now without yumdb it seems I can't do that. Which is significant step back for me with cleanly maintaining the smallest package set possible. I also can't check what packages I did install myself (yumdb search reason user). Which on other popular distros (debian or gentoo based) is trivial. For me this is a significant regression. (In reply to Havner from comment #3) > I install package A. Then I install package B. After a while I decide I > don't need/use package A anymore so I try to uninstall it. But then I see > that package A is in B's dependencies (it tries to uninstall B with A). Right, this is really something we need to support. But I'm pretty sure that we want to provide some higher level interface than direct manipulation of the "reason". I'm not sure whether there is an RFE already. It's an opposite of the bug 1125925. > I also can't check what packages I did install myself (yumdb search reason > user). Which on other popular distros (debian or gentoo based) is trivial. Actually you can with the "dnf history userinstalled" command. (In reply to Radek Holy from comment #4) > Right, this is really something we need to support. But I'm pretty sure that > we want to provide some higher level interface than direct manipulation of > the "reason". I'm not sure whether there is an RFE already. It's an opposite > of the bug 1125925. Should I create new RFE? I would really like this functionality. Both ways. Similar use case to the one above is an inverted one. I remove Y. I do autoremove and I see X is being removed (which got installed by Y's dependencies), but I use X. So I mark it 'reason user' and do autoremove again. > Actually you can with the "dnf history userinstalled" command. Thanks, didn't know about that. Seems to work fine. Swdb should provide API. What you wanna achieve in general? Probably this could be done the other way not by abusing yumdb. *** This bug has been marked as a duplicate of bug 1167239 *** No only yumdb can guarantee us that the packages are not altered. Although as described in the duplicate bug, I don't know what swdb is. |
I need to deal with the yum database. With yum you have the abillity to interact with it by using yumdb. Unfortunately I am not able to find an equivalent for dnf. If it exist then I wasn't able to find it. The use case here is to read and alter information within the yum database for further operations in a work flow. A part of the infrastructure did stuff like this: # fkt_yumdb_clean fkt_yumdb_clean() { echo "--- fkt_yumdb_clean ---" YRUID="1000" YUUID="c54a9ce5-d09a-4249-af75-9a21fe3a4741" YUMDB="/var/lib/yum/yumdb" yumdb --noplugins del changed_by ${PACKLIST} &> /dev/null yumdb --noplugins del command_line ${PACKLIST} &> /dev/null yumdb --noplugins del origin_url ${PACKLIST} &> /dev/null yumdb --noplugins set installed_by "${YRUID}" ${PACKLIST} &> /dev/null yumdb --noplugins set var_uuid "${YUUID}" ${PACKLIST} &> /dev/null find ${YUMDB} -type d -empty -exec rm --force --recursive {} \; } I thought that switching from yum to dnf should provide a similar functionality. Sadly the changes that we need to do in our infrastructure is getting way more complicated than we expected (If you recall the other use cases that I have provided).