On Mon, 01 Aug 2011, Tomasz Pala wrote: > On Mon, Aug 01, 2011 at 13:18:45 +0200, Jan Rękorajski wrote: [...] > >> Nie pomyślałeś o pakietach pozadystrybucyjnych? > > > > Nie. Nie znam takowych (w sensie wymagających krb). > [...] > >> Nie tylko mojego, starsze wersje tego co wydzieliłem są właśnie używane > >> przez różny zamknięty soft. > > > > Jaki? Serio pytam. > > Teraz np. instaluję greenpluma: [...] > > Kompilowane 1 grudnia, taka wersja mi wygląda jednak na MIT a nie > heimdala. I wolałbym to mieć zainstalowane z pakietu PLD.
Zgadza się, MIT :/ Jeżeli mamy mieć MIT w PLD to tylko w formie samych bibliotek, żeby sobie nikt w nogi nie strzelał próbując instalować resztę. Póki co i tak poprosiłem Arka żeby to wywalił z ftp. Eh... > >> > Następnym razem skonfliktuje Ci np. libheimntlm, > >> > >> Ten, który od zawsze ma so.0? - jakoś dam radę. Nie > > > > Aha, więc na czy polega problem z libkrb5? > > Że chcąc zainstalować np. równolegle so.24 i so.26 mam konflikty na > wszystkich plikach niewersjonowanych/bez wyższej werji, np. właśnie > libheimntlm.so.0 - jeśli wszystkie.so.0 są osobno, to nie próbują się > instalować na sobie, a ich aktualizację przeprowadzam tylko wtedy, gdy > dochodzą do nich nowe symbole (co nie wymaga podnoszenia SOVER). > > Ponadto taką aktualizację łatwiej zrobić w kawałkach - doinstalowuję > wyższą wersję libkrb5 przez just-install, aktualizuję wszystkie.so.0 > normalnie przez upgrade (install). > > > I w zasadzie należałoby odpowiedzieć na jedno bardzo ogólne pytanie: czy > PLD na takiej samej zasadzie, jak dopuszczamy kernele dystrybucyjne (tj. > nie robimy pakietów tak, aby konfliktowały z własnymi kompilacjami, mamy > na uwadze taką możliwość) dopuszcza formalnie instalowanie więcej niż > jednej wersji tej samej biblioteki na tej samej architekturze (czyli > ortogolalnie do multiliba)? Staramy się o ile jest to możliwe bez robienia cudów. > Rationale: stare wersje bywają wymagane przez: > 1. 3rd party software, > 2. pakiety, których nie ma w Th, a były w Ra czy Ac (!), No bez przesady, to nie można ich przebudować? API to się nie zmienia. > 3. pakiety, których z dowolnych przyczyn nie można/nie chce się, > przynajmniej w danym momencie, aktualizować - czyli szeroko rozumiany > okres przejściowy. > > Z większością bibliotek takiego problemu nie ma (np. teraz mam po 2-3 > wersje libjpeg czy libpng), problem pojawiał się z openssl (i tam > wydzieliłem bez niczyich sprzeciwów rok temu podpakiet engines, rev. > 1.225) oraz cały czas z heimdalem (szczególnie jak przeszło tornado > krb5). > > >> zauważyłeś/przeczytałeś również, że właśnie takie były zgrupowane (skoro > >> im się wersja nie zmienia, to praktycznie jest mało prawdopodobne, aby > >> kiedykolwiek skonfliktowały będąc osobnym i samodzielnym bytem). > > > > Chodzi o to że były pogrupowane losowo i bez związku z ich > > przeznaczeniem/użyciem. > > Dlatego konsultuję temat - jeśli chodzi o to co było w 'support', to AFS > i NTLM są czymś zewnętrznym względem Kerberosa, więc mogłem to także > nazwać 'mechs' albo cokolwiek innego. Istotne w tym miejscu dla mnie > jest to, że będąc (jeśli dobrze to rozumiem) tylko jakimiś midendami > zachowują stabilne API. Teraz jest podzielone na (a) "to co wymagają wszyscy", (b) "to co wymagają tylko pakiety heimdal-*", (c) "to co wymaga tylko heimdal-server". Problem jest tylko z (a) i tak naprawdę jedynym wygodnym wyjściem jest zrobienie z tego 8 pakietów per biblioteka, co uważam za zdecydowany przerost formy nad treścią. > > Jaki sens ma wydzielanie libkrb5, skoro to i tak jest zlinkowane z całą > > resztą? > > Sens ma wtedy, gdy ta właśnie cała reszta nie zmieniła wersji (a akurat > krb5 najszybciej podskakuje i to się dość często zdarza) - mając osobno, > po prostu doinstalowuję nową wersję, opcjonalnie aktualizuję do nowego > release'u tę całą resztę (która zachowała wersje) i mogę pojedynczo > aktualizować aplikacje zlinkowane ze starym krb do nowego, aby > ostatecznie tę starą wersję wywalić. > > Dzisiaj wygląda to tak, że upgrade heimdal-libs wywala mi kilkanaście > ekranów (a czasem braknie bufora scrollback...), w tym jest zawsze > naście błędów (różne konflikty) oraz ze 3-4 krytyczne dla mnie usługi, > których zwyczajnie nie chcę jednocześnie ruszać, bo muszą działać (więc > po każdorazowej aktualizacji trzeba monitorować, czasem dopasować > konfiguracje itp.) - gdy jestem zmuszony już to zrobić, to którąś z > wersji tego heimdala po prostu wrzucam bezpańsko gdzieś do lib*, > ale wiem, że nie tylko ja borykam się z tym problemem i akurat ten > właśnie zestaw bibliotek stanowi prawdziwy wrzód na tyłku, co > szczególnie irytować może gdy się kerberosa w ogóle nie używa. Na takie problemy to ja używam vserverów. Wiem że mam usługę której update to będzie RPITA i nie mam ochoty na przypadkowu update to stawiam ją w vserverze i mam spokój. > > Tylko po to żeby nie trzeba było robić --force? Ale to i tak > > prędzej czy później Cię trafi bo jakaś inna biblioteka zmieni soname i > > wrócimy do tej dyskusji tylko o innej bibliotece. > > poldek:/all-avail> upgrade --test heimdal-libs-1.4-11.x86_64 > [...] > There are 122 packages to install (121 marked by dependencies), 106 to remove: > [...] > error: 14 unresolved dependencies, 1 conflicts > poldek:/all-avail> just-install heimdal-libs-1.4-11.x86_64 > [...] > file /usr/share/info/heimdal.info.gz from install of > heimdal-libs-1.4-11.x86_64 conflicts with file from package > heimdal-libs-0.7.2-1.amd64 > file /usr/share/man/man8/kerberos.8.gz from install of > heimdal-libs-1.4-11.x86_64 conflicts with file from package > heimdal-libs-0.7.2-1.amd64 > file /etc/krb5.conf from install of heimdal-libs-1.4-11.x86_64 > conflicts with file from package heimdal-libs-1.3.1-4.x86_64 > file /lib64/libasn1.so.8.0.0 from install of > heimdal-libs-1.4-11.x86_64 conflicts with file from package > heimdal-libs-1.3.1-4.x86_64 > file /lib64/libgssapi.so.2.0.0 from install of > heimdal-libs-1.4-11.x86_64 conflicts with file from package > heimdal-libs-1.3.1-4.x86_64 > file /lib64/libhdb.so.9.2.0 from install of > heimdal-libs-1.4-11.x86_64 conflicts with file from package > heimdal-libs-1.3.1-4.x86_64 > file /lib64/libheimntlm.so.0.1.0 from install of > heimdal-libs-1.4-11.x86_64 conflicts with file from package > heimdal-libs-1.3.1-4.x86_64 > file /lib64/libhx509.so.5.0.0 from install of > heimdal-libs-1.4-11.x86_64 conflicts with file from package > heimdal-libs-1.3.1-4.x86_64 > file /lib64/libkadm5clnt.so.7.0.1 from install of > heimdal-libs-1.4-11.x86_64 conflicts with file from package > heimdal-libs-1.3.1-4.x86_64 > file /lib64/libkadm5srv.so.8.0.1 from install of > heimdal-libs-1.4-11.x86_64 conflicts with file from package > heimdal-libs-1.3.1-4.x86_64 > file /lib64/libkafs.so.0.5.1 from install of > heimdal-libs-1.4-11.x86_64 conflicts with file from package > heimdal-libs-1.3.1-4.x86_64 > file /lib64/libkdc.so.2.0.0 from install of > heimdal-libs-1.4-11.x86_64 conflicts with file from package > heimdal-libs-1.3.1-4.x86_64 > file /lib64/libotp.so.0.1.5 from install of > heimdal-libs-1.4-11.x86_64 conflicts with file from package > heimdal-libs-1.3.1-4.x86_64 > file /lib64/libroken.so.18.1.0 from install of > heimdal-libs-1.4-11.x86_64 conflicts with file from package > heimdal-libs-1.3.1-4.x86_64 > file /lib64/libsl.so.0.2.1 from install of heimdal-libs-1.4-11.x86_64 > conflicts with file from package heimdal-libs-1.3.1-4.x86_64 > file /lib64/libwind.so.0.0.0 from install of > heimdal-libs-1.4-11.x86_64 conflicts with file from package > heimdal-libs-1.3.1-4.x86_64 > file /usr/lib64/heimdal/asn1_compile from install of > heimdal-libs-1.4-11.x86_64 conflicts with file from package > heimdal-libs-1.3.1-4.x86_64 > file /usr/lib64/heimdal/asn1_print from install of > heimdal-libs-1.4-11.x86_64 conflicts with file from package > heimdal-libs-1.3.1-4.x86_64 > file /usr/lib64/heimdal/slc from install of > heimdal-libs-1.4-11.x86_64 conflicts with file from package > heimdal-libs-1.3.1-4.x86_64 > file /usr/share/info/heimdal.info.gz from install of > heimdal-libs-1.4-11.x86_64 conflicts with file from package > heimdal-libs-1.3.1-4.x86_64 > file /usr/share/info/hx509.info.gz from install of > heimdal-libs-1.4-11.x86_64 conflicts with file from package > heimdal-libs-1.3.1-4.x86_64 > file /usr/share/man/man5/krb5.conf.5h.gz from install of > heimdal-libs-1.4-11.x86_64 conflicts with file from package > heimdal-libs-1.3.1-4.x86_64 > > ~: rpm -V heimdal-libs-0.7.2-1.amd64 heimdal-libs-1.3.1-4.x86_64 > S.5....T d /usr/share/info/heimdal.info.gz > S.5....T d /usr/share/man/man8/kerberos.8.gz > > Teraz jak widzisz mam coś, co chciałbym (ale nadal kawałkami) podnieść > oraz jeden zabytek (którego się prędko nie pozbędę) - ten ostatni był > już potraktowany --force (co widać na dokumentacji). > > Jeśli i tym razem dam force, to zmaltretuje mi wszystkie powyższe pliki > (może poza libkadm5clnt, bo pozostałe mają inny rozmiar). > > > Krótko mówiąc: ten sam problem, który występuje na FTP po zmianie > soname, czyli konieczność przemielenia wszystkich pakietów, zostaje > przeniesiony do maszyny użytkownika - musi w jednym secie wszystko > zaktualizować. Moja propozycja miała dać metodę na krokowe przejście do > nowej wersji, z jak najmniejszym zestawem pakietów do ogarnięcia > jednocześnie. To jest właśnie ten osławiony dependency hell. > > > Ale jeśli uważasz, że choćby niewielkie (bo nie twierdzę, że to jest > kompletne rozwiązanie) złagodzenie tego problemu jest warte podpakietów > - trudno, każdy sobie jakoś poradzi. Nie lubię półśrodków i prowizorek, a tym właśnie jest wyodrębnienie tylko libkrb5 (patrz wyżej). > > BTW właśnie wyszedł Heimdal 1.5, zobaczymy gdzie się soname zmienił... > > No ciekawe... Gdyby się zmieniły wszystkie, to mam problem z głowy:) > BTW jakiś szczególny powód, że dałeś rel. 12.1? W Th i tak nie było 12, > ale dobrze byłoby jeszcze tego 1.4 w jakiejś poprawionej formie zbudować. Zmienił się soname libgssapi.so. To co to też do osobnego pakietu, bo akurat libgssapi jest równie popularne jak libkrb5? ;) -- Jan Rękorajski | ALL SUSPECTS ARE GUILTY. PERIOD! baggins<at>mimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
