-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hello,
One just noticed that `dnf autoremove` is trying to remove `fedora- repos-modular` and `fedora-repos-rawhide-modular`.
tl;dr. fedora-repos-modular inherit installation reason from fedora- repos (DEPENDENCY) and nothing depends on fedora-repos-modular so it is not needed anymore (from the solver POV).
The fedora-repos is being pulled in by fedora-release-common (that is brought by fedora-release-workstation or others). fedora-repos is not part of the @core group in comps so its reason recorded in DNF DB is 1.
enum class TransactionItemReason : int { UNKNOWN = 0, DEPENDENCY = 1, USER = 2, CLEAN = 3, // hawkey compatibility WEAK_DEPENDENCY = 4, GROUP = 5 };
On my laptop:
❯ sqlite3 /var/lib/dnf/history.sqlite sqlite> select trans_id,name,epoch,version,release,reason from trans_item join rpm on rpm.item_id=trans_item.item_id where name like 'fedora-release%' or name like 'fedora-repos%'; 1|fedora-release-common|0|33|0.8|1 1|fedora-release-identity-workstation|0|33|0.8|1 1|fedora-release-workstation|0|33|0.8|5 1|fedora-repos|0|33|0.6|1 1|fedora-repos-rawhide|0|33|0.6|1 21|fedora-release-common|0|33|0.9|1 21|fedora-release-common|0|33|0.8|1 21|fedora-release-identity-workstation|0|33|0.9|1 21|fedora-release-identity-workstation|0|33|0.8|1 21|fedora-release-workstation|0|33|0.9|5 21|fedora-release-workstation|0|33|0.8|5 143|fedora-repos-modular|0|33|0.8|1 143|fedora-repos-rawhide-modular|0|33|0.8|1 143|fedora-repos|0|33|0.8|1 143|fedora-repos|0|33|0.6|1 143|fedora-repos-rawhide|0|33|0.8|1 143|fedora-repos-rawhide|0|33|0.6|1
The packages that have been brought by the obsoletes inherit reason (DEPENDENCY in this case) and since nothing depends on those they are automatically cleaned up on the autoremove.
I don't know where / which the fix should be: DNF, comps or both. Simply putting the fedora-repos-modular in comps won't help since DNF is only using them when running `group install/update/remove`.
So sending this email just in case somebody will see this interesting behavior. - -- Igor Raits ignatenkobrain@fedoraproject.org
On Thu, Jul 09, 2020 at 12:55:44PM +0200, Igor Raits wrote:
One just noticed that `dnf autoremove` is trying to remove `fedora- repos-modular` and `fedora-repos-rawhide-modular`.
[...]
I don't know where / which the fix should be: DNF, comps or both. Simply putting the fedora-repos-modular in comps won't help since DNF is only using them when running `group install/update/remove`.
DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on a system upgrade, because we want that package to be prensented on the system. However I worry that DNF does not possess a capability for doing it. (Except of injecting that command into some externally executed script.)
-- Petr
On Thursday, July 9, 2020 5:24:59 AM MST Petr Pisar wrote:
DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on a system upgrade, because we want that package to be prensented on the system. However I worry that DNF does not possess a capability for doing it. (Except of injecting that command into some externally executed script.)
Unless I'm mistaken, it should only be present if the user manually installed it, and opted into modularity, right?
On Thu, Jul 9, 2020, at 10:36 AM, John M. Harris Jr wrote:
On Thursday, July 9, 2020 5:24:59 AM MST Petr Pisar wrote:
DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on a system upgrade, because we want that package to be prensented on the system. However I worry that DNF does not possess a capability for doing it. (Except of injecting that command into some externally executed script.)
Unless I'm mistaken, it should only be present if the user manually installed it, and opted into modularity, right?
The agreement by FESCo was to have it as an optional component, but installed by default, IIUC. It should be added to the relevant comps groups, but I think 'yum upgrade' needs to also learn about upgrading groups.
(Side note, this is another example of where the 'yumdb' command would come in handy if there were a dnf equivalent; I wouldn't have been able to do those sqlite queries myself.)
V/r, James Cassell
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Thu, 2020-07-09 at 07:36 -0700, John M. Harris Jr wrote:
On Thursday, July 9, 2020 5:24:59 AM MST Petr Pisar wrote:
DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on a system upgrade, because we want that package to be prensented on the system. However I worry that DNF does not possess a capability for doing it. (Except of injecting that command into some externally executed script.)
Unless I'm mistaken, it should only be present if the user manually installed it, and opted into modularity, right?
No, it should be installed by default.
-- John M. Harris, Jr.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
- -- Igor Raits ignatenkobrain@fedoraproject.org
On Thursday, July 9, 2020 7:45:07 AM MST Igor Raits wrote:
On Thu, 2020-07-09 at 07:36 -0700, John M. Harris Jr wrote:
Unless I'm mistaken, it should only be present if the user manually installed it, and opted into modularity, right?
No, it should be installed by default.
What was the point of breaking it out into a separate package, if it's still going to be installed on end users' systems by default? I can obviously see it being removed on systems currently using modular repos as an issue, but I'm not sure it makes sense to throw it on for systems not currently using it.
On Thu, Jul 09, 2020 at 08:40:52AM -0700, John M. Harris Jr wrote:
On Thursday, July 9, 2020 7:45:07 AM MST Igor Raits wrote:
On Thu, 2020-07-09 at 07:36 -0700, John M. Harris Jr wrote:
Unless I'm mistaken, it should only be present if the user manually installed it, and opted into modularity, right?
No, it should be installed by default.
What was the point of breaking it out into a separate package, if it's still going to be installed on end users' systems by default?
The goal is to have continuity in behaviour and avoid surprises for users. Existing systems behave as before, new installations get the full set of packages available, but users who wish to may opt out. This is also what got approved by FESCo.
I can obviously see it being removed on systems currently using modular repos as an issue, but I'm not sure it makes sense to throw it on for systems not currently using it.
It is being removed without taking into account if the user has any modular packages installed. But even if they don't, that's not what we want/agreed to do, see above.
Zbyszek
On Thu, 2020-07-09 at 16:45 +0200, Igor Raits wrote:
On Thu, 2020-07-09 at 07:36 -0700, John M. Harris Jr wrote:
On Thursday, July 9, 2020 5:24:59 AM MST Petr Pisar wrote:
DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on a system upgrade, because we want that package to be prensented on the system. However I worry that DNF does not possess a capability for doing it. (Except of injecting that command into some externally executed script.)
Unless I'm mistaken, it should only be present if the user manually installed it, and opted into modularity, right?
No, it should be installed by default.
Are you talking about upgrades here, or fresh installs?
It is not being installed on fresh installs presently, and as I read the ticket, that was intended, per your comment: https://pagure.io/fesco/issue/2114#comment-653352 "Probably best way would be going back to "Boltron" (IIRC how that thing was called) and have modular repos in their own fedora-repos subpackage which are enabled by default, but the package **is not installed by default.**" (emphasis added)
On Thu, 2020-07-09 at 11:09 -0700, Adam Williamson wrote:
On Thu, 2020-07-09 at 16:45 +0200, Igor Raits wrote:
On Thu, 2020-07-09 at 07:36 -0700, John M. Harris Jr wrote:
On Thursday, July 9, 2020 5:24:59 AM MST Petr Pisar wrote:
DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on a system upgrade, because we want that package to be prensented on the system. However I worry that DNF does not possess a capability for doing it. (Except of injecting that command into some externally executed script.)
Unless I'm mistaken, it should only be present if the user manually installed it, and opted into modularity, right?
No, it should be installed by default.
Are you talking about upgrades here, or fresh installs?
It is not being installed on fresh installs presently, and as I read the ticket, that was intended, per your comment: https://pagure.io/fesco/issue/2114#comment-653352 "Probably best way would be going back to "Boltron" (IIRC how that thing was called) and have modular repos in their own fedora-repos subpackage which are enabled by default, but the package **is not installed by default.**" (emphasis added)
Oh, looking at it again, now I see this: https://pagure.io/fesco/issue/2406#comment-658315
which seems to suggest that FESCo expects fedora-repos-modular to be installed out of the box. Well, in yesterday's and today's Rawhide (default Server DVD install) it wasn't, openQA caught this. On my first reading of #2114 I figured this was intentional and adjusted openQA to install fedora-repos-modular , but it sounds like it's actually a bug and comps and/or kickstarts and/or package dependencies will need to be changed.
On 09. 07. 20 20:19, Adam Williamson wrote:
On Thu, 2020-07-09 at 11:09 -0700, Adam Williamson wrote:
On Thu, 2020-07-09 at 16:45 +0200, Igor Raits wrote:
On Thu, 2020-07-09 at 07:36 -0700, John M. Harris Jr wrote:
On Thursday, July 9, 2020 5:24:59 AM MST Petr Pisar wrote:
DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on a system upgrade, because we want that package to be prensented on the system. However I worry that DNF does not possess a capability for doing it. (Except of injecting that command into some externally executed script.)
Unless I'm mistaken, it should only be present if the user manually installed it, and opted into modularity, right?
No, it should be installed by default.
Are you talking about upgrades here, or fresh installs?
It is not being installed on fresh installs presently, and as I read the ticket, that was intended, per your comment: https://pagure.io/fesco/issue/2114#comment-653352 "Probably best way would be going back to "Boltron" (IIRC how that thing was called) and have modular repos in their own fedora-repos subpackage which are enabled by default, but the package **is not installed by default.**" (emphasis added)
Oh, looking at it again, now I see this: https://pagure.io/fesco/issue/2406#comment-658315
which seems to suggest that FESCo expects fedora-repos-modular to be installed out of the box. Well, in yesterday's and today's Rawhide (default Server DVD install) it wasn't, openQA caught this. On my first reading of #2114 I figured this was intentional and adjusted openQA to install fedora-repos-modular , but it sounds like it's actually a bug and comps and/or kickstarts and/or package dependencies will need to be changed.
Yes, I was waiting for https://src.fedoraproject.org/rpms/fedora-repos/pull-request/62 to be mergeable before proceeding further.
Suddenly it was merged as part of https://src.fedoraproject.org/rpms/fedora-repos/pull-request/65 -- so I quickly created https://pagure.io/fedora-comps/pull-request/510 to avoid this situation.
Unfortunately, I wasn't sure if this is the best approach and it wasn't merged right away. I was not expecting the fedora-repos change to be merged before we figure this out :(
FTR the details are handled via https://fedoraproject.org/wiki/Changes/ModularReposSubpackage and the tracking bug is https://bugzilla.redhat.com/show_bug.cgi?id=1852028
On Thu, 2020-07-09 at 07:36 -0700, John M. Harris Jr wrote:
On Thursday, July 9, 2020 5:24:59 AM MST Petr Pisar wrote:
DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on a system upgrade, because we want that package to be prensented on the system. However I worry that DNF does not possess a capability for doing it. (Except of injecting that command into some externally executed script.)
Unless I'm mistaken, it should only be present if the user manually installed it, and opted into modularity, right?
The slightly missing context is that the package is new and did not exist until a couple of days ago. Previously modular repos were part of fedora-repos , they have now been split into a separate subpackage which is not be installed by default on fresh installs, effectively meaning the whole modularity system is now optional and not available by default, only if the user runs 'dnf install fedora-repos-modular'.
What we're dealing with now is awkward consequences of this change for existing installs, where we'd probably want to *keep* modular repos, especially if any modules are actually enabled.
On Thu, Jul 09, 2020 at 11:09:57AM -0700, Adam Williamson wrote:
What we're dealing with now is awkward consequences of this change for existing installs, where we'd probably want to *keep* modular repos, especially if any modules are actually enabled.
Is it a terrible idea to suggest that MBS insert a "Requires: fedora-repos-modular" into all of the packages built in that system?
On Thu, Jul 09, 2020 at 02:15:03PM -0400, Matthew Miller wrote:
On Thu, Jul 09, 2020 at 11:09:57AM -0700, Adam Williamson wrote:
What we're dealing with now is awkward consequences of this change for existing installs, where we'd probably want to *keep* modular repos, especially if any modules are actually enabled.
Is it a terrible idea to suggest that MBS insert a "Requires: fedora-repos-modular" into all of the packages built in that system?
Does rpmbuild have such capability?
-- Petr
On 09. 07. 20 14:24, Petr Pisar wrote:
On Thu, Jul 09, 2020 at 12:55:44PM +0200, Igor Raits wrote:
One just noticed that `dnf autoremove` is trying to remove `fedora- repos-modular` and `fedora-repos-rawhide-modular`.
[...]
I don't know where / which the fix should be: DNF, comps or both. Simply putting the fedora-repos-modular in comps won't help since DNF is only using them when running `group install/update/remove`.
DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on a system upgrade, because we want that package to be prensented on the system. However I worry that DNF does not possess a capability for doing it. (Except of injecting that command into some externally executed script.)
Can we amend dnf system-upgrade to do this?
On Friday, July 10, 2020 4:39:21 AM MST Miro Hrončok wrote:
On 09. 07. 20 14:24, Petr Pisar wrote:
On Thu, Jul 09, 2020 at 12:55:44PM +0200, Igor Raits wrote:
One just noticed that `dnf autoremove` is trying to remove `fedora- repos-modular` and `fedora-repos-rawhide-modular`.
[...]
I don't know where / which the fix should be: DNF, comps or both. Simply putting the fedora-repos-modular in comps won't help since DNF is only using them when running `group install/update/remove`.
DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on a system upgrade, because we want that package to be prensented on the system. However I worry that DNF does not possess a capability for doing it. (Except of injecting that command into some externally executed script.)
Can we amend dnf system-upgrade to do this?
Wouldn't that install modular repos on systems that end users have removed it from? Is there a way around that?
On 10. 07. 20 23:35, John M. Harris Jr wrote:
DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on a system upgrade, because we want that package to be prensented on the system. However I worry that DNF does not possess a capability for doing it. (Except of injecting that command into some externally executed script.)
Can we amend dnf system-upgrade to do this?
Wouldn't that install modular repos on systems that end users have removed it from? Is there a way around that?
My idea was:
if fedora-repos-modular is installed: dnf mark install fedora-repos-modular else: pass
On Friday, July 10, 2020 2:53:30 PM MST Miro Hrončok wrote:
On 10. 07. 20 23:35, John M. Harris Jr wrote:
DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on a system upgrade, because we want that package to be prensented on the system. However I worry that DNF does not possess a capability for doing it. (Except of injecting that command into some externally executed script.)
Can we amend dnf system-upgrade to do this?
Wouldn't that install modular repos on systems that end users have removed it from? Is there a way around that?
My idea was:
if fedora-repos-modular is installed: dnf mark install fedora-repos-modular else: pass
Ah, gotcha. Sounds like a plan.
On 11. 07. 20 1:59, John M. Harris Jr wrote:
On Friday, July 10, 2020 2:53:30 PM MST Miro Hrončok wrote:
On 10. 07. 20 23:35, John M. Harris Jr wrote:
DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on a system upgrade, because we want that package to be prensented on the system. However I worry that DNF does not possess a capability for doing it. (Except of injecting that command into some externally executed script.)
Can we amend dnf system-upgrade to do this?
Wouldn't that install modular repos on systems that end users have removed it from? Is there a way around that?
My idea was:
if fedora-repos-modular is installed: dnf mark install fedora-repos-modular else: pass
Ah, gotcha. Sounds like a plan.
Since there was no followup, I've created
https://bugzilla.redhat.com/show_bug.cgi?id=1860408
On Fri, Jul 10, 2020 at 02:35:05PM -0700, John M. Harris Jr wrote:
On Friday, July 10, 2020 4:39:21 AM MST Miro Hrončok wrote:
On 09. 07. 20 14:24, Petr Pisar wrote:
On Thu, Jul 09, 2020 at 12:55:44PM +0200, Igor Raits wrote:
One just noticed that `dnf autoremove` is trying to remove `fedora- repos-modular` and `fedora-repos-rawhide-modular`.
[...]
I don't know where / which the fix should be: DNF, comps or both. Simply putting the fedora-repos-modular in comps won't help since DNF is only using them when running `group install/update/remove`.
DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on a system upgrade, because we want that package to be prensented on the system. However I worry that DNF does not possess a capability for doing it. (Except of injecting that command into some externally executed script.)
Can we amend dnf system-upgrade to do this?
Wouldn't that install modular repos on systems that end users have removed it from? Is there a way around that?
It won't. If a package is not installed, the command will fail.
-- Petr
On Thursday, July 9, 2020 3:55:44 AM MST Igor Raits wrote:
I don't know where / which the fix should be: DNF, comps or both. Simply putting the fedora-repos-modular in comps won't help since DNF is only using them when running `group install/update/remove`.
What's to fix? Sounds like a feature, not a bug. It's well reasoned above, nothing depends on it.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Thu, 2020-07-09 at 07:35 -0700, John M. Harris Jr wrote:
On Thursday, July 9, 2020 3:55:44 AM MST Igor Raits wrote:
I don't know where / which the fix should be: DNF, comps or both. Simply putting the fedora-repos-modular in comps won't help since DNF is only using them when running `group install/update/remove`.
What's to fix? Sounds like a feature, not a bug. It's well reasoned above, nothing depends on it.
While it is behaving as it technically should, this is unexpected for the users. That's the only reason why I brought it here.
-- John M. Harris, Jr.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
- -- Igor Raits ignatenkobrain@fedoraproject.org
On 09. 07. 20 12:55, Igor Raits wrote:
I don't know where / which the fix should be: DNF, comps or both. Simply putting the fedora-repos-modular in comps won't help since DNF is only using them when running `group install/update/remove`.
How much crazy would it be to call `dnf group upgrade core` equivalent on system-upgrade?
See also, https://bugzilla.redhat.com/show_bug.cgi?id=1845562