RPM - koniec problemów z brakującymi plikami

[Tomasz Kłoczko]

On 30 May 2002, Arkadiusz Miskiewicz wrote:

> Filip Kalinski <fk181140 w zodiac.mimuw.edu.pl> writes:
> 
> > > Osobiście nie widzę zalety posiadania %test. IMO dobrym miejscem
> > > dla testów jest %build jak np. %{!?debug:%{__make} test} - część aplikacji
> > > pod make test ma podpięte testy regresji.
> > > 
> > 
> > To właśnie jest według mnie brzydkie. Pakiety powinno się według mnie
> > testować w trakcie ich budowania, ale nie w fazie %build.
> > W trakcie testu pakiet jest już zbudowany i nie powinno to siedzieć w
> > tej samej sekcji.
> W jaki sposób chcesz testować pakiety? Na dodatek te już zbudowane,
> których binarki i np. shared dane siedzą w DESTDIR czyli zupełnie
> innym miejscu niż test mógłby tego wymagać?
> 
> Te programy które warto testować mają regresion testy na dzieńdobry
> po kompilacji bez jakiejkolwiek instalacji czyli wywołania testów
> pasują do %build. Przykład - postgresql i make check.

Gdyby wywołanie skryptów %___test{,_pre,_post} było ulokowane między
obcnymi %___build* i %___install*, to przykładowo przez -bT
--short-circuit moznaby mając zbudowany pakiet wykonać tylko test tego co
się zbudowało.

Dyskusyjne może być jeszcze IMHO to gdzie testować pakiet ? czy juz po
%build czy dopiero po %install ? Być może dobrze byłoby mieć wręcz dwie
grupy sktyptów testowych ?

Inne rozwiązanie mogłoby być takie że zamiast dodawać osobną grupę
%___test{_pre,__body,__post} możanby to odwrócić i dodać test w każdej
obecnej sekcji czyli pojawiłyby się %___{prep,build,install,clean}_test
(?).
Z pónktu widzenia niejako "symetrii" rozwiązanie może nawet wypadałoby
pójść właśnie tą ścieżką (?) bo nie byłoby to rozwiązanie ad choc
tylko dodawałoby to test do kazdej sekcji dając dodatkową funkcjonalność.

Z innej jeszcze strony już nawet teraz możnaby np. w posgresie wykonywać
"make check" w %___buil_post. Tewgo typu podejście nie miałoby możliwości
wywołania tylko testu ale też uniemożliwiałoby pominięcie testu przy
pełnym budowaniu (co *też* miałoby swoje pozytywy). Dodatkowo nie
wymagałoby to żadnych dodatkowych modyfikacji w stosyunku do orginalnej
funkcjinalności rpm-a.

Wdaje mi się że że nad tym jak robić testowanie można się jeszcze troche
pozastanawiać zanim zacznie się wprowadzać jakieś bardziej wiążce
modyfikacje speców czy samego rpm-a. W tym sensie obecne modyfikacje z
dodaniem testowania w rpm-ie potraktowałbym jako pierwszą przymiarkę do
tematu.

Ktoś widzi w tym jeszcze jakąś inna ścieżkę którą warto
prześledzić/uwzględnić w rozważaniach ? albo widzi jakieś dodatkowe 
aspekty w powyższym ?

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*