Bug 1313240

(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.

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.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

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

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

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.

Created attachment 1196299 [details]
packaging.log

Created attachment 1196300 [details]
dnf.log

I created PR that solve the problem: https://github.com/rhinstaller/anaconda/pull/774

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.

I have seen that patch was not applied to the f25 branch. Hopefully it works in master :-)

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.