Zepsułem RPMa....

[Jacek Konieczny]

On Sun, Jan 04, 2004 at 02:46:27AM +0100, Jakub Bogusz wrote:
> Ż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.

No może przesadziłem. Odczuwalnych różnic na razie nie ma. Ale są pewne
subtelne różnice, które nie wiadomo kiedy wyjdą. Chociażby to że nasz
wrapper generował zależności dla całego pakietu, a wewnętrzny genreator
robi zależności dla poszczególnych plików.

> > 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.*.

Ale cały ten nasz automat do zależności to był IMHO wielki hack.
Chociażby ta ilość śmieci które wypluwał przez to rpmbuild pod koniec
budowania pakietu. Gdy budowało się coś przez ssh potrafiło to znacznie
wydłużyć czas budowania pakietu. 

> 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.

To byłoby pewne rozwiązanie, tyle że trudne do zaimplementowania
(modyfikacja kodu RPMa). I też nie widzę sensu przepuszczania listy
wszystkich plików przez zewnętrzny skrypt, gdy tylko czasami coś ma 
z tego wyniknąć.

Może popróbuję załatwić to co robiły nasze skrypty w samym rpmie. Tylko
niech mi każdy napisze czego by od takiego automatu oczekiwał. Nie ma
sensu implementować wszystkich makr _noauto, jeżeli nie wszystkie są
potrzebne.

> 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])

Błędy poldka raczej powinny być w poldku rozwiązywane. Inna sprawa, że
takie kompresowanie zależności mogłoby być miłe.

> > 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)

A może napisze ktoś wreszcie, czemu zamiast labelowania plików jest
tylko komunikat o błędzie? AFAIK nie musi selinux działać, aby pliki
można było labelować.
 
 
> [1] tak przy okazji - coraz bardziej jestem przekonany o potrzebie
> globalnej zamiany "= [%{epoch}:]%{version}" na
> "[%{epoch}:]%{version}-%{release}".

Co by to praktycznie dało? Który release byłby wymagany, pierwszy? To
chyba na jedno wychodzi... ale pewnie po prostu czegoś nie rozumiem.

> 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.

To IMHO też powinno się także w poldku załatwić. Także musiałby być
jakiś sposób na automatyczny wybór ekwiwalentów przez poldka. Bo mnie
strasznie wkurza exim instalowany zawsze gdy potrzeba /usr/lib/sendmail.

Pozdrowienia,
        Jacek