Samba

[Tomasz Kłoczko]

On Thu, 12 Jul 2001, Jacek Konieczny wrote:

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

To zauważ, że to sie zemści na autorach takiego projekrtu :>
Po za tym pole manewru na jakim operuje ac/am/lt dotyczy tylko zasobów
źródłowych czyli makr aclocal, configire.{in,ac} i plików Makefile.am. To
co z tego jest generowane to osobna bajka.

> 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

Owszem. Za jakiś czas jak wszyscy pzrejdą na uzywanie nowszego ac bezie to
możliwe. Niemniej ze względyu na to, że czasami jest używany libtool, a
autor użył starszej wersji libtoola to regeneracja zasobów libtoola
pociąga za soba regenerację całej reszty (podobnie jest z gettextem).

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

Lepiej jest to poprawić żeby pewne sekwencje w %install mogłby wglądać
niemal identycznie, a patcha z poprawką podesłać maintainerowi.

O ile komuś wydaje się, że regenrowanei zasobów ac/am/lt pociągnie za sobą
koniecznosć wykonywanai dużej ilości poprawek gdzie indziej to
zauważyłbym, że praktyka regenerowaniz zasobów w Debianie przez ostanie
lata (co jest niemal nakazem packaging policy) wyrugowało takie kwiatki
niemal całkowicie. Można tu ładnie się ukłonić w stronę Debian devel team.
Widać to już wyraźnie, bo jak na razie po pzrebudowaniu juz parudziesiąt
pakietów na nowym ac nie było jeszce ani razu konieczności wrzucania jakiś
poprawek pod ac 2.50.

Jednolitość ma być zachowana na poziomie źródłowym zasobół do ac/am/lt. To
co się z tych zasobów generuje czyli aclocal.m4, configure czy kilka
innych to (jeszcze raz) już osobna bajka i tak dokładnie to ma działać :)
Zalezniość jest niemal taka jak miedzy testem źródłowym programół i kodem
wynikowym (tylko pierwsze ma myć możliwie szeroko przenośne).

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

Tak dokładnie zostało zrobione. Znaczy sie %configure jest przystosowane
do ac 2.50 a %configure2_13 do starego.

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*