PSA: dnf autoremove cleans fedora-repos-modular

[Igor Raits]

-----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(a)fedoraproject.org&gt;
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8G97AACgkQEV1auJxc
> Hh6SkBAAo4iTvTmSImNbSRAZe6VzKfUJ1gBPjgMITEueM7pxa8zlZ7g2bOpl1UiI
> TD+DKI953Qk2gZcN+WBvkQO13Cef/FD/lp6nGXvyo87mOs2ThSc+a6UgufEBceVY
> Z5kGCoCQnfA6JkBtRtFdMbsCvVKtSRSOFJXlW7DCybLGKizUlFPqHdug0qxGpoO2
> XWldoX0Bw0F11Pr2FqujZXlcfXe5G51lkfPFnChc0a4O0+d0/AsWZJ0dM0l1ff6l
> GT43t+boiw9Dwp8KEBZTh7uTWQAeLAo9UxGIs2T2oZikHNwSSo13N6nwcS6x2XYd
> AaHVET5dn4tITH9WjiknS9IHy06D5MZ8pWBRs46aav52Ro6GxNYeALYdhjaM2heG
> mMGkjAWkXJ0qtaRR9qi68CfQiDfQjzYe0JXEHJTrLV+Pv42OrJJJoq7NWGOJbqV0
> T9DYJoO63W74q/rttMNVMIBG8GtzbTBqoxuP9ooykpAzRv2LPn1Jc1L3eEBXSO0w
> QW0SH5i6v6OgajCrc813TytboOua9zDZ55ENP0dJNXjqAiznZJjqrYG3RWUJH4cA
> qx6xygK3OvZHm9vuL4VnXCp4wW/TDGf8MNGF0hoF75IbRN1+nrAAtGorx9BdV2g+
> SvTV1Cs9CPyOKy0Q2brILtBZq6em6JNzkFAMg5h9xoce4brbyA8=
> =UXSc
> -----END PGP SIGNATURE-----

[Petr Pisar]

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

[John M. Harris Jr]

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?

-- 
John M. Harris, Jr.

[James Cassell]

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

[Igor Raits]

-----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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail] 
- -- 
Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8HLXMACgkQEV1auJxc
> Hh5HOA/7Bf+x4zEaow3IVuBEbDgg97oe76kivIOyHnCySWp8xPVCgHPAo4NnBem1
> 534aECZMKZO6zRfSVPjkvxiImUy51TKkMy//OOUl8YJrb/wD6fuUEr3BrMkvDbdC
> ztIswL7wnnPLAQIE36JbmzvOLcyfZUp867rgbB7nDCwZ+3GAX1u4q8UZXCn/4FZl
> z624gtab1VGqddvN38nih+nGPMTOXLGEafhGaz5Y9tuFcZKA1nfSPn8HDNNieNNK
> 3lii2e9WHFgWJc7pbahDGbJGRC1YK8wDLDtfcr7FG9VBtkyWsErjI1VEhd5YUCld
> ex8aFRvA5SnxuvZriyDWr+DTITQXmGEPYxbXSpCM7Tufl42ZYccWr1EV0w5bWjf3
> jKkM/zzb2P8CGomA6XWNkO43fVwjG6LTHpsq1h4q8EomXUfRNh4UfMYtOC5U3Nj1
> 5sHaMJJzzPHtzpBLEeYX2ns323bEr59Nc3qsbmfI7hiyBZffXYC1/LkJIaMxW7Dy
> Fufswm13S06330VGt1QEaa379opyUkLcFMs8SdGjGY5RCTA2CEyEL0VbZuwSC+ql
> B7bK0MvzuPtZpZ6CRgJnd0gMlMo29NQ9GOetYzLgHk52TkvTpj35vPtcv4/klRVI
> lKxwyizOi2aAWB+tMq3LTfs3N48/XTygMIZcavOp2p6b/EJc//o=
> =oXCM
> -----END PGP SIGNATURE-----

[John M. Harris Jr]

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.

-- 
John M. Harris, Jr.

[Zbigniew Jędrzejewski-Szmek]

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

[Adam Williamson]

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)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Adam Williamson]

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.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Miro Hrončok]

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

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Adam Williamson]

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.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Matthew Miller]

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?

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Petr Pisar]

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

[Miro Hrončok]

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?

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[John M. Harris Jr]

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?

-- 
John M. Harris, Jr.

[Miro Hrončok]

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

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[John M. Harris Jr]

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.

-- 
John M. Harris, Jr.

[Miro Hrončok]

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

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Petr Pisar]

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

[John M. Harris Jr]

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.

-- 
John M. Harris, Jr.

[Igor Raits]

-----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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail] 
- -- 
Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8HMmoACgkQEV1auJxc
> Hh6K0g//b+BUTmjacqKE2nktWTdJGjmvqhVOuCvKp65i/EQV9CMtGidex3mEZnMN
> M/BT1eT8ZhLAh+4X1CVYxLzmknpOSKBbeK48kjBLzSXFvLRifgw7GXwnTkwp7TG7
> jBlXI+k+qQZYx/Bsm09tgMNfiljHf0nsg7VpMkI4oVxmECx143LpNbZii8RI3dFc
> 0LX8vJ4KcEuE4Md3pORCOMGL6SDYrdBr/H0b9X2isY/JlsMWvIqMI1dZyodz5jMZ
> 2wCcscU7khpRNxmDI3xgnUgq9FwJnfKDciXG6EhUXTxA86kn1G7GvLaOw5zdZdDG
> 9mNjVaDLyL9Ik7fmbzY60/0mAYA4QK4L9s3yt/dVKDNP8LCCJR/ny+zMApimQ1jH
> Irgy4/XNJYWyhCARqGjoXGOLlguW3vjaTfA7+xZzvm1Hjk9D8fgAkvFQWwpzeFIm
> /Xj+nL4L35Zz5uOxYznUg/nmASV1jK+kvgGkf+RsGTx+MtYyURRekngNjVfT8BCb
> 3DRSmaE9EN9EH4A5ZBZNVATnhMGso6QB+B/HP5NUGBGKUlRtZ+uvGCV4c4omVZBE
> t5ep9yczF+uS5p+3YwzxT33AyVRnGYW2/uxuyXNEYz+yTCOAqCSk67/IpQe2wYfL
> 0oX7gu/1iNyZMYqdnnc+Crz7DbNKbmt/APbp2kP0Q5f4a7EYWCo=
> =j6pN
> -----END PGP SIGNATURE-----

[Miro Hrončok]

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

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok