[devel] q: проблемы со сборкой необычной программы

[Vladimir Lettiev <crux@syktsu.ru>]

собираю в пакет tcng ( http://tcng.sourceforge.net ). хочется опробовать 
эту систему контроля трафика.

Программа состоит из двух компонент tcng и tcsim. Первая собственно 
компилятор правил для tc - с ним проблем нет, а вот tcsim - эммулятор 
для проверки работы создаваемых правил - самый интересный компонент и с 
ним проблемы.

Необычность tcsim в том, что он требует исходники ядра и исходники 
iproute2. Такие требования заставили поломать голову как их ему 
обеспечить. В Buildreq указал kernel-source-2.4.27, исходники iproute2 
вместе с патчами вытащил из соотвествующего srpm и сложил их к tcsim. Но 
сборка не получилась, проблему создают патчи, а точнее 
iproute2-2.4.7-alt-fixes.patch:

....
gcc -pipe -Wall -O2 -march=i586 -mcpu=i686 -Wstrict-prototypes -Werror 
-D_GNU_SOURCE -include ../include-glibc/glibc-bugs.h -I/usr/include/db4 
-I/home/crux/RPM/BUILD/tcng/tcsim/klib/include -I../include 
-DRESOLVE_HOSTNAMES   -c -o ll_types.o ll_types.c
In file included from 
/home/crux/RPM/BUILD/tcng/tcsim/klib/include/linux/netdevice.h:11,
                  from ll_types.c:23:
/home/crux/RPM/BUILD/tcng/tcsim/klib/include/linux/in.h:8: error: 
redefinition of `struct in_addr'
/home/crux/RPM/BUILD/tcng/tcsim/klib/include/linux/in.h:16: error: 
redefinition of `struct sockaddr_in'
/home/crux/RPM/BUILD/tcng/tcsim/klib/include/linux/in.h:27: error: 
conflicting types for `IPPROTO_TCP'
/usr/include/netinet/in.h:43: error: previous declaration of `IPPROTO_TCP'
/home/crux/RPM/BUILD/tcng/tcsim/klib/include/linux/in.h:28: error: 
conflicting types for `IPPROTO_UDP'
/usr/include/netinet/in.h:49: error: previous declaration of `IPPROTO_UDP'
/home/crux/RPM/BUILD/tcng/tcsim/klib/include/linux/in.h:29: error: 
conflicting types for `IPPROTO_ESP'
/usr/include/netinet/in.h:65: error: previous declaration of `IPPROTO_ESP'
....


Без этого патча (и ещё одного зависимого) сборка проходит, но что 
получилось в итоге остаётся догадываться. В чём тут может быть проблема?

И ещё задаюсь вопросами: может ли таскать пакет с собой исходники 
другого пакета? Как поступать с исходниками ядра: требуется ли наложение 
кучи имеющихся патчей на него или "так сойдёт"? Какие в итоге должны 
быть "правильные" зависимости (жёсткие к версии ядра и iproute2 или 
вообще от них независящие) у такого пакета?

-- 
С уважением, Владимир Леттиев aka crux <crux@syktsu.ru>