kded4 i ntrack

[Bartosz Świątek]

W dniu 29 marca 2011 10:37 użytkownik Łukasz Maśko
<ed w yen.ipipan.waw.pl> napisał:
> Dnia wtorek, 29 marca 2011, Bartosz Świątek napisał:
> [...]
>> > W związku z tym moje pytanie, czy to dlatego, że nikt tego nie
>> > zauważył, czy po prostu jest to celowe postępowanie.
>>
>> Tak, to celowe ze jest dobrze.
>
> Przeczytaj, o czym jest cały wątek. Pokazałem, że kde4-kdelibs nie zależy od
> ntracka, ani pośrednio ani bezpośrednio, a jednak kded4, który jest właśnie
> w kde4-kdelibs, używa libntrack - co przy ostatnim upgrade ntracka objawiło
> się permanentnym segfaultem przy starcie kded4. Zresztą nie dziwne, że nie
> zależy tak po prostu, bo ldd kded4 nie wykazuje zależności od ntrack (musi
> być jakaś pośrednia). Akurat kded4-runtime nic tutaj nie ma do rzeczy (kde4-
> kdelibs od niego też nie zależy).

Czyli sugerujesz, ze robia jakis weak link na libntrack? Raczej watpie
i ZTCP w linuksie to nie bylo takie chop siup z tym weak linkiem.
Teorii mozna miec duzo i kazda sprowadza sie do tego ze w kdeowku
panowie developerzy sami nie wiedza co jest BRem do czego a co
koliduje. W takiej sytuacji jaka opisales i wiedzac ze kdelibs ntracka
nie wymaga do niczego, smiem twierdzic ze ntrack nawet konfliktuje
przy budowie kdelibs i nie powinien byc w ogole widziany. Jako ze
jednak jest, to cudnie kde sobie go linkuje, nie wiem, nie pytaj mnie
po co. To tylko teoria.

W kazdym razie, za czasow kiedy paczkowalem ntracka, tylko
kde4-kdebase-runtime go wymagal do budowy, stad tylko tam jest BRem.



-- 
"I'm living proof if you do one thing right in your career, you can
coast for a long time. A LOOOOONG time." -Guy Kawasaki