Bug 1313240 - keep /var/lib/dnf/groups.json file on the system
Summary: keep /var/lib/dnf/groups.json file on the system
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 23
Hardware: All
OS: All
unspecified
high
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-03-01 08:50 UTC by abyss.7
Modified: 2016-12-20 19:09 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-20 19:09:00 UTC
Type: Bug


Attachments (Terms of Use)
packaging.log (92.68 KB, text/plain)
2016-08-31 10:19 UTC, Jiri Konecny
no flags Details
dnf.log (1.20 KB, text/plain)
2016-08-31 10:20 UTC, Jiri Konecny
no flags Details

Description abyss.7 2016-03-01 08:50:55 UTC
I want to make my Fedora installation shine and polished, i.e. I don't want to have any extra package besides those that I explicitly require: it's like a "world" set mechanism in Gentoo. The "dnf mark", "dnf autoremove" and "dnf group" mechanisms in Fedora fit this purpose perfectly.

But there are the following inconsistencies.

1. By default no groups are installed! - What Anaconda installs something that doesn't correlate with a groups on my system - almost all of the installed packages are marked as user-installed.

2. I can't change the reason of installed package in yumdb without reinstalling it. It's very inconvenient to remove all core packages just to reinstall them as a Core group. Also it's almost impossible to do from the same machine.

3. I can't install only some of the optional packages from the group - e.g. I don't need _all_ of the optional fonts, but I don't want also to mark them as user-installed.

4. I can't easily see the reason of package installation and the groups that mention it.

Comment 1 Honza Silhan 2016-03-13 19:01:19 UTC
(In reply to abyss.7 from comment #0)
> 1. By default no groups are installed! - What Anaconda installs something
> that doesn't correlate with a groups on my system - almost all of the
> installed packages are marked as user-installed.

Then Anaconda should select them as groups installed. Looking at clean Fedora distribution I can't see any group installed, even though at least Core should be marked so. I have tested installing the group from Python DNF API and it's correctly installed and marked. Setting `--installroot` in DNF also saves group information in the right directory - <installroot dir>/var/lib/dnf/groups.json.

I don't know why `reason` of the installed packages is preserved but group information (/var/lib/dnf/groups.json file) not.

Let's track this issue in this bug report. Reassigning to Anaconda...

> 2. I can't change the reason of installed package in yumdb without
> reinstalling it. It's very inconvenient to remove all core packages just to
> reinstall them as a Core group. Also it's almost impossible to do from the
> same machine.

`dnf group mark install ....` should mark the packages installed as a group.

> 3. I can't install only some of the optional packages from the group - e.g.
> I don't need _all_ of the optional fonts, but I don't want also to mark them
> as user-installed.

You can use combination of `with-optional` switch with `-x` (exclude).

> 4. I can't easily see the reason of package installation and the groups that mention it.

You can type: "sudo dnf history info <pkg>" to see command line of the package installation.

Comment 2 David Shea 2016-03-14 15:48:42 UTC
groups.json is never created. This is because the GroupPersistor is only set to save the group data if Base.trans_success is True, and at the time Base.close is called by anaconda, it is not. This is because anaconda runs Base.do_transaction in a separate process, so the changes to Base.trans_success are not visible.

I do not know offhand why the transaction is run in a separate process. It was setup that way by Ales, with the commit message: "DNFPayload: initial version.".  The suspicion on #anaconda is that it is because of rpm calling chroot(). Having the entire process chroot once the payload thread starts would not be ideal.

So, either something needs to change in the logic dnf uses to write groups.json, or dnf needs to provide a means of installing to a chroot without upending the rest of the process.

Comment 3 Fedora Admin XMLRPC Client 2016-07-08 09:35:45 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 4 Jaroslav Mracek 2016-08-29 12:53:24 UTC
Request: The marking of group was refactored in DNF-2.0 (upstream version https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf-nightly/) and in combination with PR for anaconda (https://github.com/rhinstaller/anaconda/pull/741) I believe that the problem was solve. But it is out of my reach to test it. Please can you be so kind and investigate the problem with the anaconda PR and upstream dnf version? Thanks a lot

Comment 5 Jaroslav Mracek 2016-08-29 12:56:26 UTC
Request: The marking of group was refactored in DNF-2.0 (upstream version https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf-nightly/) and in combination with PR for anaconda (https://github.com/rhinstaller/anaconda/pull/741) I believe that the problem was solve. But it is out of my reach to test it. Please can you be so kind and investigate the problem with the anaconda PR and upstream dnf version? Thanks a lot

Comment 6 Jiri Konecny 2016-08-31 10:17:45 UTC
I did testing on Anaconda custom build with DNF-2.0 and it looks like the bug is still there.

The /var/lib/dnf/groups.json is not present in the system and group is not marked as installed on the installed system.

I'm attaching logs. From my understanding of the code we are changing the log file for DNF to our packaging.log so I'm attaching that. Also in DNF 2 there is change in behavior that /var/log/dnf.log is created (it wasn't with old DNF version) but there is only an exception and nothing more, I'm attaching that too.

Comment 7 Jiri Konecny 2016-08-31 10:19:46 UTC
Created attachment 1196299 [details]
packaging.log

Comment 8 Jiri Konecny 2016-08-31 10:20:13 UTC
Created attachment 1196300 [details]
dnf.log

Comment 9 Jaroslav Mracek 2016-09-07 15:37:49 UTC
I created PR that solve the problem: https://github.com/rhinstaller/anaconda/pull/774

Comment 10 Fedora End Of Life 2016-11-24 15:51:43 UTC
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 11 Jaroslav Mracek 2016-12-02 14:14:45 UTC
I have seen that patch was not applied to the f25 branch. Hopefully it works in master :-)

Comment 12 Fedora End Of Life 2016-12-20 19:09:00 UTC
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.