Poprawki: gnuserv.spec, lirc.spec

[Jakub Bogusz]

On Fri, Apr 16, 2004 at 11:28:19PM +0200, Maciek Pasternacki wrote:
> Przy okazji wyszło, że Makefile.in wymaga jeszcze jednego patcha, ze
> względu na (chyba) błąd w /usr/lib/rpm w makrze automagicznie
> gzipującym many -- otóż skrypt ten zostawia w spokoju symlinki
> w /usr/share/man/*/, w związku z czym po przekompresowaniu plików
> kończymy z symlinkami pokazującymi w kosmos.  Tutaj obszedłem to
> zmieniając ln -s na ln (hardlink kompresuje się jak trzeba, ale do
> trzech oddzielnych plików).  Czy symlinki do manuali są źle widziane,
> czy czarna magia w /usr/lib/rpm wymaga poprawki na tą okoliczność, bo
> jej nie przewidziano?

Nie używamy symlinków, tylko linków groffowych, typu

echo '.so do-czego.1' > $RPM_BUILD_ROOT%{_mandir}/man1/co.1

(s/1/numer-strony-manuala/g w razie czego)

> >> Podczas budowania nowego lm_sensors znalazłem też brak BuildRequires
> >> (bez libiconv-devel wykłada się %{configure}, a nie ma tego
> >> w zależnościach rpm-build z przyległościami, o czym świadczy chociażby
> >> fakt, że nie miałem tego w systemie):
> >
> > IIRC zależności od tego skrupulatnie próbujemy się pozbyć. Albo ac/am
> > do poprawki albo budowanie pakietu.
> 
> No, tak, ale łatać czegoś kalibru lircd na bibliotekę, której nie
> znam, się nie podejmuję, a w tej chwili nie buduje się mimo obecności
> wszystkich BuildPrereq, a to chyba jednak nie jest dobre zachowanie.
> Chyba że funkcjonalność libiconv-devel jest w jakimś podpakiecie
> glibca, którego też nie miałem -- ale wtedy to on powinien być
> w zależnościach...

API/ABI libiconv jest w samym libc (funkcja iconv(), plik nagłówkowy
<iconv.h>). Linkowanie czegokolwiek używającego glibc z zewnętrzną
libiconv jest tylko nadmiarową zależnością.

Moduły do konwersji zestawów znaków są w osobnym pakiecie iconv
(budowanym z glibc.spec), ale to nie ma znaczenia przy samej kompilacji
programów używających iconv().


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/