Podzielenie heimdal-libs

[Jan Rękorajski]

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