[rpm] Rozwiązywanie wirtualnych właściwości na nazwy pakietów

[Jakub Bogusz]

On Fri, Aug 22, 2003 at 11:07:23AM +0200, Paweł Gołaszewski wrote:
> On Wed, 20 Aug 2003, Radoslaw Zielinski wrote:
> > W trakcie budowania, zależności od znajdowanych przez autoskrypty
> > wirtualnych właściwości typu foo(bar) są rozwiązywane na nazwy
> > zainstalowanych pakietów, w których występują.
> > 
> > Problem w tym, że do pakietu wynikowego wpada zależność od wszystkich
> > pakietów, które daną właściwość udostępniają -- coraz częściej jest >1.
> > 
> > Przykłady: perl(base) -> perl-base i perl-Class-Fields,
> > perl(Filter::Util::Call) -> perl-modules i perl-Filter.
> > 
> > Proponowane rozwiązania:
> > 
> > 1. Wywalić to precz.  Wada: uzależnienie od narzędzia poldkopodobnego
> >    lub dobrej{ pamięci, intuicji, znajomości dystrybucji}.
> > 
> > 2. Nie rozwiązywać, jeśli rozwiązuje się na >1 pakiet.  Wada:  
> >    niedeterministyczność; nie wiemy, czy nie istnieją inne pakiety,
> >    udostępniające tę właściwość, wiemy tylko, że nie są zainstalowane w
> >    trakcie budowania.

Może da się znaleźć jakieś lepsze kryterium?
Problem dotyczy części modułów Perla - jeśli lista jest znana i niezbyt
długa, można dopisać je do pliku noautoreqdep.
(biblioteki to inna sprawa, zamienników z tym samym ABI jest b.mało
- OpenGL, Java... i chyba wszystko?)

Teraz to jest taka ładna konstrukcja ;), ale chyba nie da się tego
kryterium (>1 pakietu dostarczającego daną własność) bez przepisania na
wolniejszą pętlę po własnościach:

| # package names only for SONAMES, perl(module) and pear(module)
| grep -e '.\+\.so\|perl(.\+)\|pear(.\+)' ${REQS} | \
|         grep -v -e "^\(${noreqdep}\)\$" | tr '\n' '\0' | \
|         LC_ALL=C xargs -r -0 -- rpm -q --whatprovides --qf '%{NAME}\n' 2>/dev/null | \
|         grep -v "no package provides" | LC_ALL=C sort -u

Tak naprawdę to by się przydała "kompresja" zależności, i to na dwóch
etapach (generowania zależności i instalacji). Nawet poldek sobie nie
radzi w niektórych przypadkach (IIRC: jeśli w ramach transakcji dołączy
jakiś pakiet wymagany przez coś "losując" jedną z dostępnych wersji,
a potem napotka jakąś ściślejszą zależność wymagającą innej wersji
pakietu, niż początkowo "wylosowana").

Tzn.:
- z Requires: "foo", "foo >= 1.2", "foo >= 2.0" zostawiać tylko to
  ostatnie [teraz to musiałoby być w samej binarce rpm-a, bo tylko tam
  jest znany komplet zależności... albo przynajmniej w poldku, żeby się
  instalacje nie wywalały]

- jeśli jakaś własność jest dostarczana przez pakiety A i B, a B wymaga
  A, to dawać zależność tylko od A [to się nawet da zrobić
  w find-requires-wrapperze, ale sporym kosztem...]

> > Ja optuję za 1.  IMO i tak się kiedyś na tym skończy.
> 
> Ja raczej za 2 opcją.
> Co by nie powiedzieć to rozwiązywanie zależności jest wygodne na małych 
> systemach, gdzie rzeczy typu poldek są zbyt wielkie. Mam taką maszynę, 
> gdzie ładowanie poldka kończy się OOM. Byłbym bardzo niepocieszony, gdybym 
> musiał się przedzierać przez wpisy w postaci surowej...

Nie tylko to - dyskusja była wiele razy.
Ściąganie ponad 4MB bazy tylko po to, żeby uzyskać czytelne zależności
to przesada.
Po 100Mbitowej sieci z lokalnego mirrora ciągnie się szybko, ale po
przytkanym nawet 0.5Mbitowym łączu już nie, a co dopiero przez modem.
Czas uruchamiania poldka (wczytującego na dzień dobry lokalną bazę
rpm-a) nie jest zaniedbywalny w porównaniu z rpm -qpR.
Brak potrzeby korzystania z zewnętrznego serwisu typu rpmfind.net, żeby
nie mając lokalnej bazy ani mirrora pakietów dowiedzieć się, czego tak
naprawdę wymaga ściągnięty pakiet, od dawna jest zaletą PLD.
W Debianie mają czytelne zależności w pakietach (nie tylko w apcie)
- mamy być gorsi? :P


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