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 (
> > >
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
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
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
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
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
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:
> > > >
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
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
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
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
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:
>
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
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,
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
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
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
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
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
>
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
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
21 matches
Mail list logo
