Zepsułem RPMa....

[Jakub Bogusz]

On Sun, Jan 04, 2004 at 12:35:29AM +0100, Jacek Konieczny wrote:
> ...przyznaję się bez bicia.
> 
> Włączyłem wewnętrzny generator zależności. Bez niego w ogóle nie było
> kolorowania plików, które jest potrzebne żeby sensownie instalować
> 32-bitowe pakiety na np. AMD64.

> Zależności wygenerowane przez wewnętrzny generator
> będą zawsze bardziej zgodne z tym co jest w innych dystrybucjach niż
> zależności wygenerowane przez skrypty używane tylko w PLD.

Że co? Zależności w 4.3.* są generowane przez ten sam generator
(wywoływany z zewnątrz przez rpmdeps).
Oprócz perlowych i pearowych, ale przełączenie na wewnętrzny generator
tego niczego nie zmienia.

> Jednak zmiana ta wyłącza część rzeczy:
> 
> - generowanie zależności od pakietów (np. ncurses) gdy znaleziona jest
>   zależność od pliku/biblioteki (np. libncurses.so.5.3).
>   IMHO to i tak nie było potrzebne (poldek jest od tego), a sprawiało
>   problemy (chociażby z libGL).

Tylko po co poldka uruchamiać, skoro do tej pory te zależności załatwiał
automat?
Akurat libGL zostało rozwiązane globalnie w 4.3.*.

> - makra _noauto* nie działają
> 
>   były one chyba tylko używane do 3 rzeczy:
> 
>   - wywalania zależności od libGL.* - ten problem odpada - patrz wyżej
> 
>   - wywalania zależności od specjalnych bibliotek z tym samym soname
>     co "normalne" (np. libpthread z valgrind) - tu wystarczy zdjąć -x
>     z bibliotek które nie mają być uwzględnione w zależnościach
> 
>   - dla uniknięcia nieprawidłowych zależności perlowych. To jest
>     potrzebne, ale w tym przypadku można obsługę _noauto*
>     zaimplementować w skryptach perl.{prov,req}

perlowych, pearowych, interpreterów opcjonalnych skryptów, zależności
od bzdurnych bibliotek (jak w java-*), czegokolwiek.

> To chyba tyle istotnych zmian. Prosiłbym wszystkich o zastanowienie się
> co jeszcze mogło z tego wyniknąć, jeśli coś złego, to co się da z tym
> zrobić. No i o potestowanie czy to działa.

Myślałem raczej o wstawieniu przepuszczania wygenerowanych zależności
przez zewnętrzny (albo częściowo wewnętrzny, częściowo zewnętrzny -
niektóre rzeczy łatwiej załatwić skryptem niż w C) filtr między ich
generowaniem a zapisaniem do pakietu.
I tu można by od razu zależności kompresować (np. "R: p", "R: p >= n",
"R: p >= m" dla m>n daje się skrócić do "R: p >= m" - może poldek trochę
rzadziej by się gubił w zależnościach - w przypadku dostępnych kilku
źródeł to przestało być narzędzie działające nieinteraktywnie[1])

> Uwaga: RPM z HEAD w tej chwili NIE NADAJE się do normalnego użytku na
> builderach (zależności perlowe)!!!

Hm, ciekawe kto pierwszy zapomni i go puści do Ac? ;)
(i tak ta wersja co jest już jest zepsuta :/ rpm -V nie nadaje się do
użytku)


[1] tak przy okazji - coraz bardziej jestem przekonany o potrzebie
globalnej zamiany "= [%{epoch}:]%{version}" na
"[%{epoch}:]%{version}-%{release}".
Kolejny argument: przy dostępnych wielu źródłach z pakietami różniącymi
się tylko release (norma w Ra) robi się straszny bałagan; z
choose_equivalents_manually przy instalacji większej liczby pakietów
dostaję taki quiz, że mam dosyć, a bez - często instalacja się wywala.


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/