SPECS: syslog-ng.spec 1.62->1.63 [gotar]

[Jakub Bogusz]

On Tue, Jul 02, 2002 at 12:13:12PM +0200, Marcin Bohosiewicz wrote:
> On Tue, 2 Jul 2002, Bartosz Jakubski wrote:
> > Dnia 02 lip o godzinie 07:35:19 +0200, Marcin Bohosiewicz napisał(a):
> > > On Mon, 1 Jul 2002, Bartosz Jakubski wrote:
[...]
> > > Wiec zakladajac, ze changelog w specu jest po to by nie
> > > trzeba bylo siegac do CVS przy byle potrzebie sprawdzenia
> > > historii rozwoju speca, dobrze by bylo by on i to co jest
> > > w cvs log sie zgadzalo. Stad ten zakaz.
> > 
> > Nie widzę korzyści płynących ze zgadzania się logów co do literki.
> > "Dobrze by było" mnie nie przekonuje, utrata integralności jest żadna,
> > a mamy poprawę estetyki.
> Czegos co zwykly uzytkownik PLD nawet nie zobaczy :>

Zobaczy: rpm -q --changelog <pakiet>

> Zaproponowalem Tomkowi na ircu dwa wyjscia dot. changelogow,
> ale uznal ze to w tej chwili (przy stosowaniu sie developerow do
> zakazu zmian w cahnegelogach) za zbedna strate czasu.
> Owe pomysly sa to (do zastosowania jest jeden z nich, nie oba):
> 
> 1. regeneracja  _calego_ changeloga z cvs log przy kazdym cvs commit,
> czyli obojetnie co ktos tam poprawi to CVS i tak wrzuci to co wynika
> z cvs log dla danego speca.
> 
> 2. usuniecie z repo changelogow ze specow i doklejanie ich z cvs log
> do speca dopiero na etapie budowania pakietu przez buildery.

Potencjalne problemy:
1. Makra rpm-a w changelogach - jak fajnie wygląda rozwinięte %configure
w rpm -q --changelog - da się zrobić workaround zamieniający nieparzystą
liczbę '%' na parzystą (lub po prostu dwa)

2. Jest parę innych rzeczy występujących w cvs-owych changelogach
powodujących, że rpm nie chciał budować pakietu - trzeba było ręcznie
poprawiać.

3. Inne brzydkie rzeczy, np. duuużo pustych linii lub ciąg "CVS: --[...]--"

4. Pomyłki zmieniające zupełnie sens commit loga (np. zapomnienie
o słowie "not") - mogą wprowadzić w błąd osobę przeglądającą changelog
pakietu. W cvs log/diff między kolejnymi rewizjami i tak widać o co chodzi.


-- 
Jakub Bogusz