Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?

[Jaroslav Mracek]

On Fri, Feb 11, 2022 at 7:42 PM Miro Hrončok  wrote:

> On 11. 02. 22 13:50, Jaroslav Mracek wrote:
> >  > No we didn't and it will make the feature less usable - see
> reported issues
> >  > during testing in original request (
> >  > https://bugzilla.redhat.com/show_bug.cgi?id=1699672#c74
> > ).
> >
> > Miro's reply was: "That was expected and we can make sure our
> > packaging guidelines discourage Recommedns with full [NEVR]". Then
> there was
> > follow-up discussion with general agreement that the example from
> #c74 was in
> > fact a packaging mistake. In fact there was some discussion of
> amending the
> > guidelines.
> >
> >
> > DNF is not a component only in Fedora and we have to support the LEGACY
> point
> > of view. Changing guidelines is not an option because they are not
> mandatory
> > but something as a recommendation. People will anyway ship packages with
> > versioning of relation dependencies because they want, they can and they
> need
> > them. Creating such a rule will only make things worse.
>
> Let's take a step back, since I feel we've derailed. We appear to be
> discussing
> two related but different things:
>
>   - behavior of a new dnf option
>   - whether or not the new option should be turned on by default in Fedora
>
> If dnf needs to support use cases of another distro (say legacy RHEL),
> that can
> easily happen by not changing the default there. Maybe I just don't see
> the
> whole picture?
>

The feature was requested by Fedora and RHEL community to resolve multiple
use cases. It means it was requested to provide the feature by default
enabled on both  systems  (Fedora 36, RHEL9). Personally I am really scared
to ship something to RHEL but not into Fedora.



> What I'd like to understand better is how option 3 (which seems to be
> preferred
> by you, if I am not mistaken) makes this situation any different. Why do
> you
> assume the impact on legacy systems will be smaller if we go with option 3?
>

With LEGACY user cases I was directly reacting to the option to change
packaging guigelins. DNF in fedora 36 must handle correctly packages
builded for even older Fedoras. The same for the RHEL. Anyway the version
problem is not a problem anymore.

We have autodetection of unmet weak dependencies that works correctly with
one exception - situations when rich dependencies are used. Therefore
modifying only this part will have the best effect on the feature. I do not
say that it is perfect and there will be no pain, but we can improve it.
Postponing it will only move discovering problems to the future.
The autodetection can work nearly perfectly for Recommends but even there
it will not resolve every situation perfectly, because two people with the
same operation can have completely different expectations. Therefore we
have to optimize it so that the majority of users will be happy.
The other situation is with Supplements - we do not have all information
like for Recommends because they are stored in available metadata
(repositories) that are gone after metadata refresh. It means we have to
make an assumption for autodetection. According to reports the default
assumption was wrong for Supplements with rich deps. What I do here is to
modify the algorithm for autodetection and see whether it will satisfy more
user cases that present implementation. The algorithm cannot be perfect
because it is based on the assumption of what users want.
As I said several times, it is very complicated but I believe it will be
beneficial to users and postponing it will not help in any way.




> Changing guidelines might as well work in Fedora, as Zbyszek said. We can
> fix
> the packages easily. I can even offer my help to do it and even attempt to
> do
> it in c9s.
>
> I understand that packagers will always break the rules. That is not a
> phenomenon specific to weak dependencies. When they do, we can fix it. And
> when
> we don't fix it, the worst case is they get the behavior that was the
> default
> until now. That doesn't sound that bad to me: Packagers who follow the
> rules
> will get nice things, packagers that don't will get things that ain't that
> nice
> but still work.
>

Changing packaging guidelines is not an option for 99.9% of the community.
Miro I know you can but not others, therefore I develop a solution that
resolves the issue with versions without changing packing guidelines. And
it works, therefore we do not need to change them.


> Another thing I'd like to understand from your POV is why would packagers
> actually *need* exactly-versioned Recommends. Could you please give me an
> example use case? I understand why they might *assume they need* it,
> because
> packaging is complex and this might seem like a reasonable thing to do for
> somebody who's not been following this discussion. The new guideline would
> help
> explain that, making the things better, not worse.
>

Don't ask 

Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?

[Miro Hrončok]

On 11. 02. 22 21:58, Kevin Kofler via devel wrote:

Miro Hrončok wrote:

Another thing I'd like to understand from your POV is why would packagers
actually *need* exactly-versioned Recommends. Could you please give me an
example use case? I understand why they might *assume they need* it,
because packaging is complex and this might seem like a reasonable thing
to do for somebody who's not been following this discussion. The new
guideline would help explain that, making the things better, not worse.


IMHO, exactly-versioned Recommends are always a mistake, and when a
maintainer writes:
Recommends: foo = 1.2.3-4
what they really mean, and should write, is:
Recommends: foo
Requires: (foo = 1.2.3-4 if foo)


Or, considering this is usually a recommended sub-package, have:

(main package)
Recommends:   %{name}-extras

%package extras
Requires:%{name} = %{version}-%{release}

(with %_isa and/or %epoch if needed)

And only use the if-dep if this is not the case.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?

[Kevin Kofler via devel]

Miro Hrončok wrote:
> Another thing I'd like to understand from your POV is why would packagers
> actually *need* exactly-versioned Recommends. Could you please give me an
> example use case? I understand why they might *assume they need* it,
> because packaging is complex and this might seem like a reasonable thing
> to do for somebody who's not been following this discussion. The new
> guideline would help explain that, making the things better, not worse.

IMHO, exactly-versioned Recommends are always a mistake, and when a 
maintainer writes:
Recommends: foo = 1.2.3-4
what they really mean, and should write, is:
Recommends: foo
Requires: (foo = 1.2.3-4 if foo)

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?

[Miro Hrončok]

On 11. 02. 22 13:50, Jaroslav Mracek wrote:

 > No we didn't and it will make the feature less usable - see reported 
issues
 > during testing in original request (
 > https://bugzilla.redhat.com/show_bug.cgi?id=1699672#c74
).

Miro's reply was: "That was expected and we can make sure our
packaging guidelines discourage Recommedns with full [NEVR]". Then there was
follow-up discussion with general agreement that the example from #c74 was 
in
fact a packaging mistake. In fact there was some discussion of amending the
guidelines.


DNF is not a component only in Fedora and we have to support the LEGACY point 
of view. Changing guidelines is not an option because they are not mandatory 
but something as a recommendation. People will anyway ship packages with 
versioning of relation dependencies because they want, they can and they need 
them. Creating such a rule will only make things worse.


Let's take a step back, since I feel we've derailed. We appear to be discussing 
two related but different things:


 - behavior of a new dnf option
 - whether or not the new option should be turned on by default in Fedora

If dnf needs to support use cases of another distro (say legacy RHEL), that can 
easily happen by not changing the default there. Maybe I just don't see the 
whole picture?


What I'd like to understand better is how option 3 (which seems to be preferred 
by you, if I am not mistaken) makes this situation any different. Why do you 
assume the impact on legacy systems will be smaller if we go with option 3?


Changing guidelines might as well work in Fedora, as Zbyszek said. We can fix 
the packages easily. I can even offer my help to do it and even attempt to do 
it in c9s.


I understand that packagers will always break the rules. That is not a 
phenomenon specific to weak dependencies. When they do, we can fix it. And when 
we don't fix it, the worst case is they get the behavior that was the default 
until now. That doesn't sound that bad to me: Packagers who follow the rules 
will get nice things, packagers that don't will get things that ain't that nice 
but still work.


Another thing I'd like to understand from your POV is why would packagers 
actually *need* exactly-versioned Recommends. Could you please give me an 
example use case? I understand why they might *assume they need* it, because 
packaging is complex and this might seem like a reasonable thing to do for 
somebody who's not been following this discussion. The new guideline would help 
explain that, making the things better, not worse.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?

[Zbigniew Jędrzejewski-Szmek]

On Fri, Feb 11, 2022 at 02:05:15PM +0100, Kevin Kofler via devel wrote:
> Am Freitag, 11. Februar 2022 13:50:57 CET schrieb Jaroslav Mracek:
> > On Tue, Feb 8, 2022 at 7:30 PM Zbigniew Jędrzejewski-Szmek <
> > zbys...@in.waw.pl> wrote:
> > > Hmm, but why is metadata of repository needed? IIUC, all deps (including
> > > rich)
> > > are part of the package header, i.e. are in the RPM database for a package
> > > that is currently installed. E.g. 'rpm -qR …' shows rich deps.
> > > 
> > > So, even if inefficient, we could just do a loop over 'rpm -qaR' and 'rpm
> > > -qaP'
> > > and resolve each and every Recommends to either true or false.
> > 
> > We need them to fulfill the workflow in DNF and for detection of unmet
> > dependencies for Supplements. The process is as follows:
> > 1. Iteration over all installed content and test recommends whether they
> > are on the system or not. For Supplements: Iterate over all supplements of
> > available packages and test them whether their supplemented package is
> > installed.
> > 2. Set the rule in the solver to not use packages that are supposed to be
> > on the system but they are not as a candidate to satisfy weak dependencies
> > 3. Run solver to create a transaction with required dependencies and weak
> > dependencies.
> 
> Yes, unmet reverse dependencies (Supplements) can only be found with
> repository metadata. By definition, they will not show up in installed
> package metadata, because they are reverse and unmet, so they are found in
> the package that is not installed.
> 
> I think that is the real issue that makes the langpack dependencies hard to
> handle, not the fact that they are boolean (rich dependencies).

Thank you both, I completely missed that part. This is indeed a problem.

> The issue is that to know whether the dependency was *previously* unmet,
> one would need the *previous* state of the repository metadata. But the
> depsolving happens *after* refreshing the repository metadata, only the
> local package metadata still reliably reflects the old state. So DNF would
> have to back up the pre-sync metadata somewhere.
> 
> So maybe the proper workaround for the langpack issue is not to handle
> boolean dependencies specially, but to handle reverse dependencies
> (Supplements) specially? Though I would still prefer seeing a solution that
> always actually does what users expect without quirks, if at all possible.

Right. So to handle previously-unmet Supplements nicely, we would need
to know what Supplements were relevant and unmet (available in the
whole package set, but unmet despite the supplemented package being
installed locally). Wouldn't it be possible for dnf to just keep a
flat list of such "unmet relevant Suggests" values? It seems that Suggests
is used quite sparingly, so having a flat list of 1k-2k entries should
not be a problem. E.g. at the end of each dnf transaction, just write
down the whole list of "unmet relevant Suggests".

> > DNF is not a component only in Fedora and we have to support the LEGACY
> > point of view. Changing guidelines is not an option because they are not
> > mandatory but something as a recommendation. People will anyway ship
> > packages with versioning of relation dependencies because they want, they
> > can and they need them. Creating such a rule will only make things worse.

I think you are wrong here. We *can* adjust the guidelines, and we can quite
feasibly adjust packages. Doing a provenpackager-fixup of the few dozens of
wrongly-versioned packages can be easily done in a day.

> That part needs to be rediscussed then. At least Miro and I were under the
> (apparently false) impression that we had already reached agreement there,
> because you did not object at the time.

Ack.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?

[Kevin Kofler via devel]

Am Freitag, 11. Februar 2022 13:50:57 CET schrieb Jaroslav Mracek:

On Tue, Feb 8, 2022 at 7:30 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

Hmm, but why is metadata of repository needed? IIUC, all deps (including
rich)
are part of the package header, i.e. are in the RPM database for a package
that is currently installed. E.g. 'rpm -qR …' shows rich deps.

So, even if inefficient, we could just do a loop over 'rpm -qaR' and 'rpm
-qaP'
and resolve each and every Recommends to either true or false.


We need them to fulfill the workflow in DNF and for detection of unmet
dependencies for Supplements. The process is as follows:
1. Iteration over all installed content and test recommends whether they
are on the system or not. For Supplements: Iterate over all supplements of
available packages and test them whether their supplemented package is
installed.
2. Set the rule in the solver to not use packages that are supposed to be
on the system but they are not as a candidate to satisfy weak dependencies
3. Run solver to create a transaction with required dependencies and weak
dependencies.


Yes, unmet reverse dependencies (Supplements) can only be found with
repository metadata. By definition, they will not show up in installed
package metadata, because they are reverse and unmet, so they are found in
the package that is not installed.

I think that is the real issue that makes the langpack dependencies hard to
handle, not the fact that they are boolean (rich dependencies).

The issue is that to know whether the dependency was *previously* unmet,
one would need the *previous* state of the repository metadata. But the
depsolving happens *after* refreshing the repository metadata, only the
local package metadata still reliably reflects the old state. So DNF would
have to back up the pre-sync metadata somewhere.

So maybe the proper workaround for the langpack issue is not to handle
boolean dependencies specially, but to handle reverse dependencies
(Supplements) specially? Though I would still prefer seeing a solution that
always actually does what users expect without quirks, if at all possible.


DNF is not a component only in Fedora and we have to support the LEGACY
point of view. Changing guidelines is not an option because they are not
mandatory but something as a recommendation. People will anyway ship
packages with versioning of relation dependencies because they want, they
can and they need them. Creating such a rule will only make things worse.


That part needs to be rediscussed then. At least Miro and I were under the
(apparently false) impression that we had already reached agreement there,
because you did not object at the time.

   Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?

[Jaroslav Mracek]

On Tue, Feb 8, 2022 at 7:30 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Tue, Feb 08, 2022 at 02:30:30PM +0100, Jaroslav Mracek wrote:
> > On Tue, Feb 8, 2022 at 1:56 PM Kevin Kofler via devel <
> > devel@lists.fedoraproject.org> wrote:
> >
> > > Jaroslav Mracek wrote:
> > > > I am really sorry but this suggestion is incorrect. Basically we
> have 3
> > > > major misunderstandings - what is rich deps and how it is evaluated,
> what
> > > > DNF stores in the history database and how SAT solver in libsolv
> works.
> > > > Rich deps are very complex things with multiple operators (and, or,
> if
> > > > unless, with, without) and can have multiple conditions. See examples
> > > > below from
> > > >
> > >
> https://rpm-software-management.github.io/rpm/manual/boolean_dependencies.html
> > > .
> > >
> > > They are arbitrarily complicated boolean expressions, but they are
> still
> > > always boolean expressions. They evaluate to either true or false
> > > depending
> > > on the contents of the RPM database.
> > >
> >
> > Not exactly, the second part is in metada of repository. The rest
> correct -
> > the evaluation is boolean, but complicated due to complex data (reldeps)
> > and in combination with version we have a lot of fun. See `(foo if (bas
> > 4
> > with ham > 2))`. And we are still unable to do it correctly but solver
> can,
> > but only in transaction.
>
> Hmm, but why is metadata of repository needed? IIUC, all deps (including
> rich)
> are part of the package header, i.e. are in the RPM database for a package
> that is currently installed. E.g. 'rpm -qR …' shows rich deps.
>
> So, even if inefficient, we could just do a loop over 'rpm -qaR' and 'rpm
> -qaP'
> and resolve each and every Recommends to either true or false.
>

We need them to fulfill the workflow in DNF and for detection of unmet
dependencies for Supplements. The process is as follows:
1. Iteration over all installed content and test recommends whether they
are on the system or not. For Supplements: Iterate over all supplements of
available packages and test them whether their supplemented package is
installed.
2. Set the rule in the solver to not use packages that are supposed to be
on the system but they are not as a candidate to satisfy weak dependencies
3. Run solver to create a transaction with required dependencies and weak
dependencies.


> > > > Also rich dependencies contain not names and versions of packages but
> > > > dependencies satisfied by provides. It is true that we have a history
> > > > database but it contains only the name of packagase but not what they
> > > > provided.
> > >
> > > Sorry, but this confuses me: What do you need the history for? I would
> > > expect the only thing that matters to be: Is the rich dependency
> > > *currently*
> > > met (true) or unmet (false)? "Currently" as in: at the time where the
> > > dependencies are computed, where no part of the transaction has
> actually
> > > run
> > > yet. That information is present at least in the RPM database. It
> ought to
> > > be present also in the databases DNF and/or libsolv use.
> > >
> >
> > I was only answering to previous reference that all information required
> > are in the DNF database. I understand that as history
> >
> > > Rich dependencies are dynamic and they change from release to release
> > > > (version macros, ...)
> > >
> > > That is a different issue, and also happens for non-rich dependencies.
> I
> > > think we agreed back when the Change was submitted that a dependency
> that
> > > changed in any way (such as a version bump) shall always be treated as
> a
> > > new
> > > dependency, did we not?
> > >
> >
> > No we didn't and it will make the feature less usable - see reported
> issues
> > during testing in original request (
> > https://bugzilla.redhat.com/show_bug.cgi?id=1699672#c74).
>
> Miro's reply was: "That was expected and we can make sure our
> packaging guidelines discourage Recommedns with full [NEVR]". Then there
> was
> follow-up discussion with general agreement that the example from #c74 was
> in
> fact a packaging mistake. In fact there was some discussion of amending the
> guidelines.
>

DNF is not a component only in Fedora and we have to support the LEGACY
point of view. Changing guidelines is not an option because they are not
mandatory but something as a recommendation. People will anyway ship
packages with versioning of relation dependencies because they want, they
can and they need them. Creating such a rule will only make things worse.



So it seems that there is no need to treat versioned dependencies as
> special,
> i.e. a dep with with a changed version can be treated as a new dep.
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 

Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?

[Miro Hrončok]

On 08. 02. 22 14:30, Jaroslav Mracek wrote:


 > Rich dependencies are dynamic and they change from release to release
 > (version macros, ...)

That is a different issue, and also happens for non-rich dependencies. I
think we agreed back when the Change was submitted that a dependency that
changed in any way (such as a version bump) shall always be treated as a new
dependency, did we not?


No we didn't and it will make the feature less usable - see reported issues 
during testing in original request 
(https://bugzilla.redhat.com/show_bug.cgi?id=1699672#c74 
).


Yes we did, see my immediate reply [1] below the comment you just linked, and 
see my WIP change of the packaging guidelines [2].



[1] https://bugzilla.redhat.com/show_bug.cgi?id=1699672#c76
[2] https://pagure.io/packaging-committee/pull-request/1144

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?

[Zbigniew Jędrzejewski-Szmek]

On Tue, Feb 08, 2022 at 02:30:30PM +0100, Jaroslav Mracek wrote:
> On Tue, Feb 8, 2022 at 1:56 PM Kevin Kofler via devel <
> devel@lists.fedoraproject.org> wrote:
> 
> > Jaroslav Mracek wrote:
> > > I am really sorry but this suggestion is incorrect. Basically we have 3
> > > major misunderstandings - what is rich deps and how it is evaluated, what
> > > DNF stores in the history database and how SAT solver in libsolv works.
> > > Rich deps are very complex things with multiple operators (and, or, if
> > > unless, with, without) and can have multiple conditions. See examples
> > > below from
> > >
> > https://rpm-software-management.github.io/rpm/manual/boolean_dependencies.html
> > .
> >
> > They are arbitrarily complicated boolean expressions, but they are still
> > always boolean expressions. They evaluate to either true or false
> > depending
> > on the contents of the RPM database.
> >
> 
> Not exactly, the second part is in metada of repository. The rest correct -
> the evaluation is boolean, but complicated due to complex data (reldeps)
> and in combination with version we have a lot of fun. See `(foo if (bas > 4
> with ham > 2))`. And we are still unable to do it correctly but solver can,
> but only in transaction.

Hmm, but why is metadata of repository needed? IIUC, all deps (including rich)
are part of the package header, i.e. are in the RPM database for a package
that is currently installed. E.g. 'rpm -qR …' shows rich deps.

So, even if inefficient, we could just do a loop over 'rpm -qaR' and 'rpm -qaP'
and resolve each and every Recommends to either true or false.

> > > Also rich dependencies contain not names and versions of packages but
> > > dependencies satisfied by provides. It is true that we have a history
> > > database but it contains only the name of packagase but not what they
> > > provided.
> >
> > Sorry, but this confuses me: What do you need the history for? I would
> > expect the only thing that matters to be: Is the rich dependency
> > *currently*
> > met (true) or unmet (false)? "Currently" as in: at the time where the
> > dependencies are computed, where no part of the transaction has actually
> > run
> > yet. That information is present at least in the RPM database. It ought to
> > be present also in the databases DNF and/or libsolv use.
> >
> 
> I was only answering to previous reference that all information required
> are in the DNF database. I understand that as history
> 
> > Rich dependencies are dynamic and they change from release to release
> > > (version macros, ...)
> >
> > That is a different issue, and also happens for non-rich dependencies. I
> > think we agreed back when the Change was submitted that a dependency that
> > changed in any way (such as a version bump) shall always be treated as a
> > new
> > dependency, did we not?
> >
> 
> No we didn't and it will make the feature less usable - see reported issues
> during testing in original request (
> https://bugzilla.redhat.com/show_bug.cgi?id=1699672#c74).

Miro's reply was: "That was expected and we can make sure our
packaging guidelines discourage Recommedns with full [NEVR]". Then there was
follow-up discussion with general agreement that the example from #c74 was in
fact a packaging mistake. In fact there was some discussion of amending the
guidelines.

So it seems that there is no need to treat versioned dependencies as special,
i.e. a dep with with a changed version can be treated as a new dep.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?

[Jaroslav Mracek]

On Tue, Feb 8, 2022 at 1:56 PM Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> Jaroslav Mracek wrote:
> > I am really sorry but this suggestion is incorrect. Basically we have 3
> > major misunderstandings - what is rich deps and how it is evaluated, what
> > DNF stores in the history database and how SAT solver in libsolv works.
> > Rich deps are very complex things with multiple operators (and, or, if
> > unless, with, without) and can have multiple conditions. See examples
> > below from
> >
> https://rpm-software-management.github.io/rpm/manual/boolean_dependencies.html
> .
>
> They are arbitrarily complicated boolean expressions, but they are still
> always boolean expressions. They evaluate to either true or false
> depending
> on the contents of the RPM database.
>

Not exactly, the second part is in metada of repository. The rest correct -
the evaluation is boolean, but complicated due to complex data (reldeps)
and in combination with version we have a lot of fun. See `(foo if (bas > 4
with ham > 2))`. And we are still unable to do it correctly but solver can,
but only in transaction.


>
> > Also rich dependencies contain not names and versions of packages but
> > dependencies satisfied by provides. It is true that we have a history
> > database but it contains only the name of packagase but not what they
> > provided.
>
> Sorry, but this confuses me: What do you need the history for? I would
> expect the only thing that matters to be: Is the rich dependency
> *currently*
> met (true) or unmet (false)? "Currently" as in: at the time where the
> dependencies are computed, where no part of the transaction has actually
> run
> yet. That information is present at least in the RPM database. It ought to
> be present also in the databases DNF and/or libsolv use.
>

I was only answering to previous reference that all information required
are in the DNF database. I understand that as history

> Rich dependencies are dynamic and they change from release to release
> > (version macros, ...)
>
> That is a different issue, and also happens for non-rich dependencies. I
> think we agreed back when the Change was submitted that a dependency that
> changed in any way (such as a version bump) shall always be treated as a
> new
> dependency, did we not?
>

No we didn't and it will make the feature less usable - see reported issues
during testing in original request (
https://bugzilla.redhat.com/show_bug.cgi?id=1699672#c74).


>
> > I am sorry I can provide a long list of additional information to support
> > my statement but I hope it is not necessary. I also hope that it is not
> > necessary to share with you my experience in the development of DNF,
> > especially the part related to libsolv (DNF solver).
>
> I would be interested in knowing the exact technical difficulties, because
> logically, it should be possible.
>

We will be happy to help you with the code improvement. Most of the logic
is in libdnf (https://github.com/rpm-software-management/libdnf/) and
libsolv (https://github.com/openSUSE/libsolv/). Even testing would be very
helpful.

Jaroslav




>
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?

[Kevin Kofler via devel]

Jaroslav Mracek wrote:
> I am really sorry but this suggestion is incorrect. Basically we have 3
> major misunderstandings - what is rich deps and how it is evaluated, what
> DNF stores in the history database and how SAT solver in libsolv works.
> Rich deps are very complex things with multiple operators (and, or, if
> unless, with, without) and can have multiple conditions. See examples
> below from
> https://rpm-software-management.github.io/rpm/manual/boolean_dependencies.html.

They are arbitrarily complicated boolean expressions, but they are still 
always boolean expressions. They evaluate to either true or false depending 
on the contents of the RPM database.

> Also rich dependencies contain not names and versions of packages but
> dependencies satisfied by provides. It is true that we have a history
> database but it contains only the name of packagase but not what they
> provided.

Sorry, but this confuses me: What do you need the history for? I would 
expect the only thing that matters to be: Is the rich dependency *currently* 
met (true) or unmet (false)? "Currently" as in: at the time where the 
dependencies are computed, where no part of the transaction has actually run 
yet. That information is present at least in the RPM database. It ought to 
be present also in the databases DNF and/or libsolv use.

> Rich dependencies are dynamic and they change from release to release
> (version macros, ...)

That is a different issue, and also happens for non-rich dependencies. I 
think we agreed back when the Change was submitted that a dependency that 
changed in any way (such as a version bump) shall always be treated as a new 
dependency, did we not?

> I am sorry I can provide a long list of additional information to support
> my statement but I hope it is not necessary. I also hope that it is not
> necessary to share with you my experience in the development of DNF,
> especially the part related to libsolv (DNF solver).

I would be interested in knowing the exact technical difficulties, because 
logically, it should be possible.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?

[Jaroslav Mracek]

On Mon, Feb 7, 2022 at 5:20 PM Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> Miro Hrončok wrote:
> > this is about the following Fedora change:
> >
> > https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect
> >
> > In the tracking bugzilla, the relevant comment is:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=2013327#c4
> >
> > If I understand this correctly, the current implementation is not doing
> > what the change described and the change owner says the feature cannot be
> > implemented as described.
> >
> > There are several options and we should probably decide what to do before
> > beta freeze. Hence opening this discussion.
> >
> > The change summarizes as "We would like to change a default behavior
> > dnf/PackageKit/microdnf to install only newly recommended packages on
> > upgrades." however the current impementation disbales weak depndencies in
> > various other scenarios, as reported by various of our packagers e.g. in
> >
> > Bug 2048394 - dnf should pull weak dependencies in install transaction
> > Bug 2033130 - exclude_from_weak_autodetect=true effectively renders rich
> > weak dependencies useless
> > Bug 2042808 - weakdeps not working on rawhide system
>
> So, as I understand it, the core of the issue is this:
> | We have a problem to detect rich dependencies correctly in autodetections
> | because we do not know whether their conditions were met or not in past.
>
> So basically, this leaves only 2 possible options (and the remainder are
> variants thereof): either assume they were met or assume they were unmet:
>
> > The change owner proposed 4 options to move forward. I understand them as
> > follows:
> >
> > 1. do nothing, keep it broken
> > 2. disable this behavior by default, keep it optional, but keep it broken
> > 3. do not ignore already broken weak rich deps (partially reverts the
> > change)
> > 4. change the behavior on dynamically depending on the dnf command
> > used (discouraged)
>
> The status quo, i.e., 1., assumes they were met. Option 3. would assume
> they
> were unmet.
>
> Option 2. is like 1. but disables the entire feature by default.
>
> Option 4. would attempt to heuristically, depending on the command used,
> pick the behavior of 1. vs. either 2. or 3..
>
> They are basically all workarounds for the real issue, which is that the
> previous state cannot be correctly determined. Like Fabio Valentini, I
> have
> to wonder why that cannot be done. DNF should have all the required
> information in its database, or it could query RPM which also has the
> information in its database.
>

I am really sorry but this suggestion is incorrect. Basically we have 3
major misunderstandings - what is rich deps and how it is evaluated, what
DNF stores in the history database and how SAT solver in libsolv works.
Rich deps are very complex things with multiple operators (and, or, if
unless, with, without) and can have multiple conditions. See examples below
from
https://rpm-software-management.github.io/rpm/manual/boolean_dependencies.html.
Also rich dependencies contain not names and versions of packages but
dependencies satisfied by provides. It is true that we have a history
database but it contains only the name of packagase but not what they
provided. Rich dependencies are dynamic and they change from release to
release (version macros, ...)
I am sorry I can provide a long list of additional information to support
my statement but I hope it is not necessary. I also hope that it is not
necessary to share with you my experience in the development of DNF,
especially the part related to libsolv (DNF solver).


Examples:

Requires: (pkgA or pkgB or pkgC)

Requires: (pkgA or (pkgB and pkgC))

Supplements: (foo and (lang-support-cz or lang-support-all))

Requires: ((pkgA with capB) or (pkgB without capA))

Supplements: ((driverA and driverA-tools) unless driverB)

Recommends: ((myPkg-langCZ and (font1-langCZ or font2-langCZ)) if
langsupportCZ)




> E.g., foo-langpack-xx Supplements: (foo and langpacks-xx) cannot possibly
> have been already unmet if langpacks-xx was not previously installed. It
> ought to be possible for DNF to determine that automatically.
>
> So I would currently tend towards:
> * postponing the Change to F37,
>

I prefer to keep it in Fedora 36 with solution 3 (rich dependencies in weak
deps will be still fully functional like before the change). I already
started with improvements:
https://github.com/rpm-software-management/libdnf/pull/1439
DNF team is providing updates and improvements during the whole lifecycle
of Fedora.


> * implementing option 2. for F36 (i.e., adding the option as experimental
>   and disabled by default, which should not need a Change at all), AND
>

The option is or will be available in Fedora 35 but by defoult it is off
(exclude_from_weak_autodetect). I do not thing there is a reason to change
that.


> * looking further for a proper solution for F37, as I do not believe it
>   cannot be done (and 

Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?

[Jaroslav Mracek]

I would like to prefer to go with for Fedora 36:
> 3. do not ignore already broken weak rich deps (partially reverts the change)

It will enable lang packs user case but provides significant part of requested 
functionality.
I created PR (https://github.com/rpm-software-management/libdnf/pull/1439) with 
the change but it has to be tested first.

Probably it would be nice to present the state of the feature. The feature was 
delivered even into F35 but by default it is off.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?

[Zbigniew Jędrzejewski-Szmek]

On Mon, Feb 07, 2022 at 03:01:43PM -0800, Adam Williamson wrote:
> On Mon, 2022-02-07 at 15:17 +0100, Miro Hrončok wrote:
> > 
> > The change owner proposed 4 options to move forward. I understand them as 
> > follows:
> > 
> > 1. do nothing, keep it broken
> > 2. disable this behavior by default, keep it optional, but keep it broken
> > 3. do not ignore already broken weak rich deps (partially reverts the 
> > change)
> > 4. change the behavior on dynamically depending on the dnf command used 
> > (discouraged)
> 
> It's not clear to me whether any of these choices maps to "revert the
> Change and do exactly what F35 and earlier did", but on principle, that
> is the correct choice if no other choice is an improvement. It is not
> useful to change to a new behavior which is no better than the old
> behavior. If the Change can't be implemented as planned, ideally no
> change should happen at all.

Option 2. is that. The code to support this has been merged in libsolv and
dnf, so it's easier to return to status quo ante by flipping the default, then
to fully undo all changes.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?

[Adam Williamson]

On Mon, 2022-02-07 at 15:17 +0100, Miro Hrončok wrote:
> 
> The change owner proposed 4 options to move forward. I understand them as 
> follows:
> 
> 1. do nothing, keep it broken
> 2. disable this behavior by default, keep it optional, but keep it broken
> 3. do not ignore already broken weak rich deps (partially reverts the change)
> 4. change the behavior on dynamically depending on the dnf command used 
> (discouraged)

It's not clear to me whether any of these choices maps to "revert the
Change and do exactly what F35 and earlier did", but on principle, that
is the correct choice if no other choice is an improvement. It is not
useful to change to a new behavior which is no better than the old
behavior. If the Change can't be implemented as planned, ideally no
change should happen at all.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?

[Zbigniew Jędrzejewski-Szmek]

On Mon, Feb 07, 2022 at 03:25:44PM +0100, Miro Hrončok wrote:
> > 1. do nothing, keep it broken
> 
> I pretty much dislike this option. Clearly, the current behavior is not what
> was approved in this change proposal. For me, it's a bad option.

Agreed. We want to use langpacks with rich depenendecies *more*, e.g. replacing
comps with that, and it'd be a big step back if rich deps stopped working as
expected.

> > 3. do not ignore already broken weak rich deps (partially reverts the 
> > change)
> 
> This sounds like a possible path forward -- it would probably still be an
> improvement over the the Fedora 35 status quo, however the results might be
> quite surprising for the users. If we decide to do this, I think we should
> postpone to Fedora 37 neverthelss to see it in action and figure out if it's
> actually a good idea or an UX nightmare.

Agreed, this doesn't sound too great either. I think we'd be better postponing
the feature until F37 or later if we can get a solution then.

> > 4. change the behavior on dynamically depending on the dnf command used
> > (discouraged)
> 
> As stated by the change owner in the bugzilla, this is probably not a good
> idea. Even when the user types `dnf install` it sometimes upgrades some
> already installed packages and even if they type `dnf upgrade` it sometimes
> installs some new packages.

Agreed also.

> > 2. disable this behavior by default, keep it optional, but keep it broken
> 
> This only makes sense if it's likely to get fixed and enabled again in later
> Fedora release. If the plan is to disable it by default and never touch it
> again, I suppose we might as well revert it entirely. I would very much to
> see the change happening as it was advertised, even if we cannot make ti to
> Fedora 36.

Agreed.

> For the sake of an open minded discussion, I am ignoring the fact that the
> change owners themselves don't consider it doable (I think that it is
> doable, but I honestly don't know if it is realistic with the current
> resources).

I'll just say what you and others said: rpm/dnf has *all* the information about
the system, so it should be just a matter of adding plumbing to push that
information to the right layer.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?

[Miro Hrončok]

On 07. 02. 22 17:17, Kevin Kofler via devel wrote:

So I would currently tend towards:
* postponing the Change to F37,
* implementing option 2. for F36 (i.e., adding the option as experimental
   and disabled by default, which should not need a Change at all), AND
* looking further for a proper solution for F37, as I do not believe it
   cannot be done (and neither does Fabio).


And neither do I for the record. I just found it a bit unrealistic to convince 
the change owners :)


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?

[Kevin Kofler via devel]

Miro Hrončok wrote:
> this is about the following Fedora change:
> 
> https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect
> 
> In the tracking bugzilla, the relevant comment is:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2013327#c4
> 
> If I understand this correctly, the current implementation is not doing
> what the change described and the change owner says the feature cannot be
> implemented as described.
> 
> There are several options and we should probably decide what to do before
> beta freeze. Hence opening this discussion.
> 
> The change summarizes as "We would like to change a default behavior
> dnf/PackageKit/microdnf to install only newly recommended packages on
> upgrades." however the current impementation disbales weak depndencies in
> various other scenarios, as reported by various of our packagers e.g. in
> 
> Bug 2048394 - dnf should pull weak dependencies in install transaction
> Bug 2033130 - exclude_from_weak_autodetect=true effectively renders rich
> weak dependencies useless
> Bug 2042808 - weakdeps not working on rawhide system

So, as I understand it, the core of the issue is this:
| We have a problem to detect rich dependencies correctly in autodetections
| because we do not know whether their conditions were met or not in past.

So basically, this leaves only 2 possible options (and the remainder are 
variants thereof): either assume they were met or assume they were unmet:

> The change owner proposed 4 options to move forward. I understand them as
> follows:
> 
> 1. do nothing, keep it broken
> 2. disable this behavior by default, keep it optional, but keep it broken
> 3. do not ignore already broken weak rich deps (partially reverts the
> change)
> 4. change the behavior on dynamically depending on the dnf command
> used (discouraged)

The status quo, i.e., 1., assumes they were met. Option 3. would assume they 
were unmet.

Option 2. is like 1. but disables the entire feature by default.

Option 4. would attempt to heuristically, depending on the command used, 
pick the behavior of 1. vs. either 2. or 3..

They are basically all workarounds for the real issue, which is that the 
previous state cannot be correctly determined. Like Fabio Valentini, I have 
to wonder why that cannot be done. DNF should have all the required 
information in its database, or it could query RPM which also has the 
information in its database.

E.g., foo-langpack-xx Supplements: (foo and langpacks-xx) cannot possibly 
have been already unmet if langpacks-xx was not previously installed. It 
ought to be possible for DNF to determine that automatically.

So I would currently tend towards:
* postponing the Change to F37,
* implementing option 2. for F36 (i.e., adding the option as experimental
  and disabled by default, which should not need a Change at all), AND
* looking further for a proper solution for F37, as I do not believe it
  cannot be done (and neither does Fabio).

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?

[Fabio Valentini]

On Mon, Feb 7, 2022 at 3:26 PM Miro Hrončok  wrote:
>
> > 3. do not ignore already broken weak rich deps (partially reverts the 
> > change)
>
> This sounds like a possible path forward -- it would probably still be an
> improvement over the the Fedora 35 status quo, however the results might be
> quite surprising for the users. If we decide to do this, I think we should
> postpone to Fedora 37 neverthelss to see it in action and figure out if it's
> actually a good idea or an UX nightmare.

Wouldn't that revert the primary reason why users wanted this features?
I.e. "I have not installed weak dependency of package X on purpose, so
I also don't want updates of package X to pull them in again"?

It sounds like it's "not possible" to check whether weak dependencies
were satisfied before a transaction (I wonder why? dnf has all the
data here), but then, this feature is basically useless, and only
breaks some behaviour in unexpected ways, unless I misunderstand
something?

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What should we do about the "Install only newly recommended packages on upgrades" F36 change?

[Miro Hrončok]

On 07. 02. 22 15:17, Miro Hrončok wrote:

Hello,

this is about the following Fedora change:

https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect

In the tracking bugzilla, the relevant comment is:

https://bugzilla.redhat.com/show_bug.cgi?id=2013327#c4

If I understand this correctly, the current implementation is not doing what 
the change described and the change owner says the feature cannot be 
implemented as described.


There are several options and we should probably decide what to do before beta 
freeze. Hence opening this discussion.


The change summarizes as "We would like to change a default behavior 
dnf/PackageKit/microdnf to install only newly recommended packages on 
upgrades." however the current impementation disbales weak depndencies in 
various other scenarios, as reported by various of our packagers e.g. in


Bug 2048394 - dnf should pull weak dependencies in install transaction
Bug 2033130 - exclude_from_weak_autodetect=true effectively renders rich weak 
dependencies useless

Bug 2042808 - weakdeps not working on rawhide system

The change owner proposed 4 options to move forward. I understand them as 
follows:


And here I am to reply to myself.


1. do nothing, keep it broken


I pretty much dislike this option. Clearly, the current behavior is not what 
was approved in this change proposal. For me, it's a bad option.



2. disable this behavior by default, keep it optional, but keep it broken


This only makes sense if it's likely to get fixed and enabled again in later 
Fedora release. If the plan is to disable it by default and never touch it 
again, I suppose we might as well revert it entirely. I would very much to see 
the change happening as it was advertised, even if we cannot make ti to Fedora 36.


For the sake of an open minded discussion, I am ignoring the fact that the 
change owners themselves don't consider it doable (I think that it is doable, 
but I honestly don't know if it is realistic with the current resources).



3. do not ignore already broken weak rich deps (partially reverts the change)


This sounds like a possible path forward -- it would probably still be an 
improvement over the the Fedora 35 status quo, however the results might be 
quite surprising for the users. If we decide to do this, I think we should 
postpone to Fedora 37 neverthelss to see it in action and figure out if it's 
actually a good idea or an UX nightmare.


4. change the behavior on dynamically depending on the dnf command used 
(discouraged)


As stated by the change owner in the bugzilla, this is probably not a good 
idea. Even when the user types `dnf install` it sometimes upgrades some already 
installed packages and even if they type `dnf upgrade` it sometimes installs 
some new packages.



(Go see the linked comment for details.)

Please let us know what you think is best or if there is a better solution.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

What should we do about the "Install only newly recommended packages on upgrades" F36 change?

[Miro Hrončok]

Hello,

this is about the following Fedora change:

https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect

In the tracking bugzilla, the relevant comment is:

https://bugzilla.redhat.com/show_bug.cgi?id=2013327#c4

If I understand this correctly, the current implementation is not doing what 
the change described and the change owner says the feature cannot be 
implemented as described.


There are several options and we should probably decide what to do before beta 
freeze. Hence opening this discussion.


The change summarizes as "We would like to change a default behavior 
dnf/PackageKit/microdnf to install only newly recommended packages on 
upgrades." however the current impementation disbales weak depndencies in 
various other scenarios, as reported by various of our packagers e.g. in


Bug 2048394 - dnf should pull weak dependencies in install transaction
Bug 2033130 - exclude_from_weak_autodetect=true effectively renders rich weak 
dependencies useless

Bug 2042808 - weakdeps not working on rawhide system

The change owner proposed 4 options to move forward. I understand them as 
follows:

1. do nothing, keep it broken
2. disable this behavior by default, keep it optional, but keep it broken
3. do not ignore already broken weak rich deps (partially reverts the change)
4. change the behavior on dynamically depending on the dnf command used 
(discouraged)


(Go see the linked comment for details.)

Please let us know what you think is best or if there is a better solution.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure