Different package version in same environment was: Re: [bug#54261] Acknowledgement ([PATCH]: Update GTK to 4.6.1.)

Different package version in same environment was: Re: [bug#54261] Acknowledgement ([PATCH]: Update GTK to 4.6.1.)

[Zhu Zihao]

[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]


This problem is not related to that patch so I would like to discuss here.

Maxime Devos <maximedevos@telenet.be> writes:

> [[PGP Signed Part:Undecided]]
> Zhu Zihao schreef op za 12-03-2022 om 10:38 [+0800]:
>> > What if a program uses both 'pango' and gtk?  Then IIUC, it would
>> > simultanuously use pango and pango-next in the same process, which
>> can
>> > easily cause problems (see e.g. the bug report about segfaults
>> > involving multiple libcairos).

Can you show me the link of the libcairo conflict example you said?

I don't know what cause the segfaults in your example. C linker will
embed the full path of the library into the RUNPATH, unless
LD_LIBRARY_PATH is set, C library will use the dependencies they found in
link time.

>> 
>> i've asked in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44327 and
>> suggest to introduce priority mechanism like Nix. But Ludovic Courtès
>> doesn't accept my suggestion
>
> How could a priority mechanism solve the segfaults?

'priority' will let user to specify which package can override other
packages, if some of their contents overlapped with each other. Now Guix
will silently choose one. 


-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

Re: Different package version in same environment was: Re: [bug#54261] Acknowledgement ([PATCH]: Update GTK to 4.6.1.)

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 783 bytes --]

Zhu Zihao schreef op zo 13-03-2022 om 00:06 [+0800]:
> Can you show me the link of the libcairo conflict example you said?
> 
> I don't know what cause the segfaults in your example. C linker will
> embed the full path of the library into the RUNPATH, unless
> LD_LIBRARY_PATH is set, C library will use the dependencies they
> found in
> link time.

It will embed the full path of the library.  The problem is, it might
embed multiple variants of the same library in the same binary.

For the libcairo problem, see <https://issues.guix.gnu.org/47115#22>.
Turns out it wasn't a segfault but another kind of problem.
And it wasn't due to deduplication but rather buggy grafting.
Still, I suppose something similar can happen with propagation.

Greetings,
Maxime.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]