Samba

[Jacek Konieczny]

On Thu, Jul 12, 2001 at 07:47:59PM +0200, Tomasz Kłoczko wrote:
> Jeżeli zobaczy w wygenerowanym configure linijkę:
> 
> # Generated automatically using autoconf version 2.13
> 
> lub inna wskazująca na to że nie jest to coś bliskiego 2.50
> to nie będziesz mógł użyć %configure w specu.
> 
> Sa tu dwa wyjścia:
> - użuć %configure2_13,
> - zregenerować wszystki potrzebne pliki.
> 
> Pierwszego raczje bym nie polecał/unikałbym 
A ja wręcz przeciwnie. Skoro w programie jest działający skrypt
configure to powinniśmy go wykorzystać, a nie dodawać kolejne funkcje 
do %build, które nic nie robią, a kiedyś mogą się zemścić (jak autorzy
programu zmienią np. wersje autoconfa).

> po to tylko żeby mieć pewność,
> że wsparcie do ac w projekcie jest zgodne z ac 2.50.
To może zacznijmy się upewniać, że wszelkie nasze pakiety są zgodne 
z np. ANSI-C i jeżeli nie to poprawiać.

Idealny spec powinien w %build robić tylko to co jest konieczne do
skompilowania pakietu, a więc:
./configure
make

Wszelkie zmiany powinny się ograniczyć tylko do tego, aby uzyskać
kompilujący się pakiet o zadanej funkcjonalności. A więc mogą to być 
zmiany poprawiające ścieżki dostępu, opcje kompilatora (tu zadana
funkcjonalność = optymalizacja pod zadaną architekturę).
Każda zbędna funkcja (typu regeneracja skryptu konfigure) sprawia że
jest więcej kodu do zadbania, a więc potencjalnie więcej problemów.

Podobnie jest z patchami, dlatego jestem przeciwnikiem patchowania
wszystkiego na DESTDIR, jeśli w danym pakiecie da się identyczny efekt
uzystkać przez odpowiednie paramerty configure, make lub zmienne
środowiska.


> O ile przy
> regenerownia uzasobów pojawia się jakieś kłopoty i ktoś nie chce/nie
> potrafi tego poprawić to lepiej wstawić %configure2_13. 
IMHO zwykle powinno się to stosować. A tak w ogóle to nie dałoby się
zwykłego "%configure" nauczyć współpracy z nowym autoconfem?

> W przypadku kiedy regeneracja jest konieczna [...]
No i do tego powinniśmy się ograniczać.

Pozdrowienia,
        Jacek