On Mon, Jan 30, 2023 at 02:09:18PM +0100, Petr Pisar wrote:
> V Sat, Jan 28, 2023 at 06:12:11PM -0800, Gordon Messmer napsal(a):
> >
> > I don't think convincing hundreds or thousands of developers to add symbol
> > versioning to their libraries is a viable solution. I'd love to see it
> >
* Petr Pisar:
> V Sat, Jan 28, 2023 at 06:12:11PM -0800, Gordon Messmer napsal(a):
>>
>> I don't think convincing hundreds or thousands of developers to add symbol
>> versioning to their libraries is a viable solution. I'd love to see it
>> happen, but rpm/dnf should be more reliable in the
On Mon, Jan 30, 2023 at 1:27 PM Richard W.M. Jones wrote:
>
> On Sat, Jan 28, 2023 at 02:14:58AM -0600, Bruno Wolff III wrote:
> > On Fri, Jan 27, 2023 at 18:43:56 -0800,
> > Gordon Messmer wrote:
> > >
> > >Second, I'd like to suggest that in the future, at least in
> > >Fedora, for any
V Sat, Jan 28, 2023 at 06:12:11PM -0800, Gordon Messmer napsal(a):
>
> I don't think convincing hundreds or thousands of developers to add symbol
> versioning to their libraries is a viable solution. I'd love to see it
> happen, but rpm/dnf should be more reliable in the meantime.
>
Is symbol
On Sat, Jan 28, 2023 at 02:14:58AM -0600, Bruno Wolff III wrote:
> On Fri, Jan 27, 2023 at 18:43:56 -0800,
> Gordon Messmer wrote:
> >
> >Second, I'd like to suggest that in the future, at least in
> >Fedora, for any "install" or "update" operation that dnf performs,
> >dnf's default behavior
* Gordon Messmer:
> On 2023-01-28 13:03, Zbigniew Jędrzejewski-Szmek wrote:
>>> ...or "(libfoo.so.2()(64bit) with foo-libs >= x.y.z)", where x.y.z is the
>>> version of the package that provides libfoo.so.2 in the build root, which is
>>> an idea that's growing on me.
>> This is indeed a
On 2023-01-29 00:00, Zbigniew Jędrzejewski-Szmek wrote:
The version doesn't have to be major.minor.micro, though. The dependency
generator only needs to get the version of the package that provides the
.so, and use that version. As long as changes within a so version are
always backward
On Sat, Jan 28, 2023 at 06:12:11PM -0800, Gordon Messmer wrote:
> On 2023-01-28 13:03, Zbigniew Jędrzejewski-Szmek wrote:
> > > ...or "(libfoo.so.2()(64bit) with foo-libs >= x.y.z)", where x.y.z is the
> > > version of the package that provides libfoo.so.2 in the build root, which
> > > is
> > >
On Sun, Jan 29, 2023 at 12:23:49AM +0100, Fabio Valentini wrote:
> On Sun, Jan 29, 2023 at 12:03 AM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Sat, Jan 28, 2023 at 01:49:17PM -0800, Kevin Fenzi wrote:
> > > On Sat, Jan 28, 2023 at 09:03:35PM +, Zbigniew Jędrzejewski-Szmek
> > > wrote:
>
On 2023-01-28 15:23, Fabio Valentini wrote:
If I understand things correctly, this is not entirely true. RPM
generates a dependency for the soname / soversion, and some projects
include not only X, but all of X.Y.Z in that, which RPM will happily
generate Provides / Requires for
$ ls -l
On 2023-01-28 13:03, Zbigniew Jędrzejewski-Szmek wrote:
...or "(libfoo.so.2()(64bit) with foo-libs >= x.y.z)", where x.y.z is the
version of the package that provides libfoo.so.2 in the build root, which is
an idea that's growing on me.
This is indeed a shortcoming in the rpm symbol dependency
On Sun, Jan 29, 2023 at 12:03 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Sat, Jan 28, 2023 at 01:49:17PM -0800, Kevin Fenzi wrote:
> > On Sat, Jan 28, 2023 at 09:03:35PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > >
> > > This is indeed a shortcoming in the rpm symbol dependency generation
>
On Sat, Jan 28, 2023 at 01:49:17PM -0800, Kevin Fenzi wrote:
> On Sat, Jan 28, 2023 at 09:03:35PM +, Zbigniew Jędrzejewski-Szmek wrote:
> >
> > This is indeed a shortcoming in the rpm symbol dependency generation scheme.
>
> Is it though? I'm probibly reading this too quickly and missing
>
On Sat, Jan 28, 2023 at 1:23 PM Gordon Messmer wrote:
>
> On 2023-01-28 00:14, Bruno Wolff III wrote:
> > If there is a problem with not uodating dependencies when you do an
> > install or an update on selected packages, the packages dependencies
> > are not properly defined.
>
>
> By definition,
On Sat, Jan 28, 2023 at 09:03:35PM +, Zbigniew Jędrzejewski-Szmek wrote:
>
> This is indeed a shortcoming in the rpm symbol dependency generation scheme.
Is it though? I'm probibly reading this too quickly and missing
something, but isn't the underlying problem here that nghttp2 changed
abi
On Sat, Jan 28, 2023 at 12:12:40PM -0800, Gordon Messmer wrote:
> On 2023-01-28 10:22, Gordon Messmer wrote:
> > In order for rpm to do this, you'd probably have to throw out the
> > current implementation of dependency resolution that provides
> > "libfoo.so.2()(64bit)" and instead provide a
On 2023-01-28 10:22, Gordon Messmer wrote:
In order for rpm to do this, you'd probably have to throw out the
current implementation of dependency resolution that provides
"libfoo.so.2()(64bit)" and instead provide a dependency like "(foo-libs
>= 2.4 with foo-libs < 3)", at least for the
On 2023-01-28 00:14, Bruno Wolff III wrote:
If there is a problem with not uodating dependencies when you do an
install or an update on selected packages, the packages dependencies
are not properly defined.
By definition, yes. But rpm auto-detects dependencies, and rpm doesn't
do
libsoup3 depends on libnghttp2.so.14
Apparantly, either libsoup3 should depend on the minor version (in addition to
the major version), or libnghhttp2 should have bumped major, depending on the
"history" of that symbol. Probably the former (API addition in a minor bump to
the same major).
On Fri, Jan 27, 2023 at 18:43:56 -0800,
Gordon Messmer wrote:
Second, I'd like to suggest that in the future, at least in Fedora,
for any "install" or "update" operation that dnf performs, dnf's
default behavior should be checking all of the direct and indirect
dependencies of the packages
I recently helped another user repair their Fedora workation, after an
update broke gnome-shell. In their case, I believe that the problem
occurred because they had the nodejs:14 module enabled, which contained
an outdated libnghttp2 [1], but in principle, the problem can affect any
system
21 matches
Mail list logo