CD: RPM: %files -f

Tomasz Kłoczko kloczek w rudy.mif.pg.gda.pl
Sob, 12 Wrz 1998, 16:07:18 CEST


On Sat, 12 Sep 1998, Ziemek Borowski wrote:

> On Sat, Sep 12, 1998 at 03:58:19PM +0200, napisałem:
> > W większości emacsowych (i XEmacsowych) speców Packgerzy stosują 
> > zagrywkę typu 
> > %files -f nazwa_pliku_z_rzeczami_do_wsadzenia_do_paczki_binarnej_... 
> > Czy jest to z naszego punktu widzenia (definiujemy wszelkie informacjie 
> > o plikach w SPECu) dopuszczalne czy nie... 

> za stosowaniem takiej metody przemawia teoretycznie większa przenośność 
> kodu SPECa z wersji na wersję... 

Ziemek kewstia przenośności to jednak kwestia przemyślenia listy rzeczy,
które ładuje się do %files. O ile są tam nazwy zależne od architektóry czy
systemu to można się podpierać makrami %{buildarch} czy %{buildos} czy
wogóle makrami tworzonymi in situ. Raczej nie widzę pakietu którego bie
dałoby się włądować w jawną listę w %files. Zaleta takiego postępowania
chyba jest jasna .. łatwo analizuje się zawartość pakietu na podstawie
speca. W przypadku $files -f jest to ukryte i ewentualne wysszukiwanie
błędów tym samym utrudnione.

> Przeciw... zdarzały się wypadki, że dostępny binarny rpm nie zawierał 
> rzeczy tak wygenerowanych. I brak kompletności speca (choć może dzięki 
> temu bardziej był przejrzysty..., mniej wymieniania plików (z tego co wiem 
> nie mozna powiedzieć w języku speca, że interesują nas wszystkie pliki 
> z tego katalogu i jego podkatalogów o rozszerzeniu np. el.gz -- tu było 
> to robione findem, zrzucane do pliku, i przetwarzane). 
>  
> Więc jak? stosować tę metodę czy nie... jakby co wrzucam na 
> magellan:/incoming przykładowy plik tego 
> typu... (xemacs-20.4-4-files-z-f.spec) 

Ja byłbym przeciw, a jak ktoś mi podeśle speca z files -f to i tak go
przerobie ;>

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*



Więcej informacji o liście dyskusyjnej pld-devel-pl