W dniu 29 marca 2011 10:37 użytkownik Łukasz Maśko <e...@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 _______________________________________________ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl