Autoconf 2.53, Automake 1.6.1

[Jakub Bogusz]

On Thu, May 23, 2002 at 11:02:40AM +0200, Tomasz Kłoczko wrote:
> On Thu, 23 May 2002, Marcin Bohosiewicz wrote:
> [..]
> > > Hm... może na ftp jeszcze zostawić w 1.0 starsze ac/am, do /test puścić
> > > nowsze i tych nowszych używać na builderach Ra? Byłaby szansa na
> > > ukompatybilnienie dużej części pakietów.
> > 
> > To jest zly pomysl.
> > I nowe ac/am to do PLD 2.0.
> > kloczek: wydajmy juz to 1.0 bo nam znowu sie rozjedzie.

Raczej do updates, nie dopiero 2.0 (za parę lat?), wraz z nowszymi
wersjami programów GNU.

Jeżeli w 1.0 ma zostać 2.52/1.5, to trzeba cofnąć gdb do 5.1.1,
gtypist[1] do jakiejś poprzedniej wersji i chyba coś jeszcze.
I wszystkie poprawki security/ważnych błędów w programach GNU
backportować (tak jak ostatnia w fileutils).

[1] u mnie i tak się nie buduje na 2.53/1.6.1 - coś z texinfo
i gettextem.

> Poprawki na nowe ac/am są wstecznie zgodne czyli jeżeli wsparcie do ac/am 
> nie używaja nowych rzeczy to to co będzie wymagało poprawienia przejdzie
> *takaże* na ac 2.5.2/am 1.5.

Jednak nie zawsze - np. python.spec. Zrobiłem żeby działał z ac 2.53,
to się z 2.52 rozjechało.
Poza tym np. w slrn.spec jest workaround, żeby autoheader działał na
obu.

> Większość rzeczy jak zaznaczył Jakub powinna być już gotowa do nowego 
> ac/am bo częśc osób od dłuzszego czasu uzywa nowego ac/am.

Większość _podstawowych_. W ogóle nie wiem jak z GNOME, KDE[2] i innymi
GUI-owymi programami.

[2] oprócz tych, gdzie jest %configure2_13


Jak widać oba rozwiązania mają wady. Na pewno nowe ac/am nie powinny
wyjść z /test przed uzdatnieniem >99% (najlepiej wszystkich) pakietów
przebudowujących pliki auto* (teraz tego jest około 1000).
Jeśli 1.0 ma wyjść[3] przed skończeniem tego, to zostaje z 2.52/1.5.

[3] co wynika z nadal bliżej nieokreślonych warunków (żeby coś z tego
wyszło, powinniśmy określić listę rzeczy, które muszą działać - bo tak
pojawiają się nowe listy TODO dotyczące pojedynczych pakietów i tak
w kółko)


-- 
Jakub Bogusz