On Sun, Sep 15, 2019 at 11:36 PM Neal Gompa wrote:
>
> DNF does have some broken behaviors, but this isn't one of them.
I can't confirm whether this is a broken behavior but I have a strong
heuristic that I suspect would make DNF appear wrong here.
If I have RPM foo-1 installed that obsoletes b
Neal Gompa wrote:
> I consider YUM's behavior of Obsoletes to have been fundamentally
> broken since the beginning of time. This age-old argument between you
> and the DNF developers on Obsoletes needs to die.
I don't see how this can be an "age-old argument", considering that I only
discovered t
On Sun, Sep 15, 2019 at 4:22 PM Kevin Kofler wrote:
>
> Dridi Boukelmoune wrote:
> > In other words, a package superseded by another still gets its
> > Obsoletes entries taken into account? I breaks the POLA as far as I'm
> > concerned, it means the only way to undo such a mistake is first to
> >
Dridi Boukelmoune wrote:
> In other words, a package superseded by another still gets its
> Obsoletes entries taken into account? I breaks the POLA as far as I'm
> concerned, it means the only way to undo such a mistake is first to
> have the mistake only happen in the updates repository, and work
On Fri, Sep 13, 2019 at 10:19 AM Kevin Kofler wrote:
>
> And finally, unlike the old YUM, DNF also processes Obsoletes from old
> versions of packages in the GA repositories, so an update can no longer
> safely withdraw an Obsoletes. This is a DNF issue and we need a solution in
> DNF, but the DN
Le vendredi 13 septembre 2019 à 12:18 +0200, Kevin Kofler a écrit :
> Nicolas Mailhot via devel wrote:
> > That's an historical artefact, that made sense when everyone used
> > the
> > same dozen font on windows, and when each and everyone of them
> > could be
> > treated as a special case. Nowaday
Nicolas Mailhot via devel wrote:
> That's an historical artefact, that made sense when everyone used the
> same dozen font on windows, and when each and everyone of them could be
> treated as a special case. Nowadays, even on Linux (what a change a
> decade made) the font catalog is huge, and font
Le 2019-09-13 10:39, Kevin Kofler a écrit :
Nicolas Mailhot via devel wrote:
The correct thing would have been never to create a narrow liberation
subpackage in the first place since narrow is just a face of a font
(like bold).
In theory, in an ideal world, that makes sense. But in practice, M
Nicolas Mailhot via devel wrote:
> The correct thing would have been never to create a narrow liberation
> subpackage in the first place since narrow is just a face of a font
> (like bold).
In theory, in an ideal world, that makes sense. But in practice, M$ ships
separate "Arial" and "Arial Narro
Le 2019-09-13 00:05, Kevin Kofler a écrit :
Marius Schwarz wrote:
(in short: no update to 2.00.5-3 was possible via dnf, as packages
refer
to 2.00.3-1 directly)
They don't actually refer to liberation-fonts-2.00.3-1, but to
liberation-
narrow-fonts, which liberation-fonts-2.00.3-1 claims to
Marius Schwarz wrote:
> (in short: no update to 2.00.5-3 was possible via dnf, as packages refer
> to 2.00.3-1 directly)
They don't actually refer to liberation-fonts-2.00.3-1, but to liberation-
narrow-fonts, which liberation-fonts-2.00.3-1 claims to Provide, but does
not actually provide.
So t
11 matches
Mail list logo
