[devel] repocop and *-debuginfo conflicts

[Igor Vlasenko]

On Wed, Mar 16, 2011 at 08:51:51PM +0300, Alexey Tourbin wrote:
> On Wed, Mar 16, 2011 at 03:54:18PM +0200, Igor Vlasenko wrote:
> > Уважаемые коллеги,
> > 1) когда у нас появились debuginfo пакеты, то repocop начал ругать 
> > файловые конфликты между основной версией библиотеки и compat-пакетом.
> > Я собираюсь выключить эту ругань, поскольку в силу специфики 
> > debuginfo пакетов эти конфликты (по .so.debug файлам)
> > на текущий момент неизлечимы и вины майнтайнера в них нет.
> 
> Сейчас не совсем корректно пакуются .so.debug симлинки.  Вообще,
> выполняется перегруппировка симлинков - они "приписываются" к бинарику.
> Это сделано для того, чтобы не создавать "почти пустых" symlink-only
> пакетов e.g. libfoo-devel-debuginfo.  Тогда, например, если симлинк
> libfoo.so -> /usr/lib64/libfoo.so.0 запакован в пакете libfoo-devel,
> то симлинк libfoo.so.debug -> /usr/lib/debug/usr/lib64/libfoo.so.0.debug
> всё равно отходит в пакет libfoo-debuginfo.

понял. Вроде бы, обычно это не создает проблем, а если вдруг созлает,
то не -debuginfo виноват, как писал выше.
 
> Проблема сейчас в том, что пакуются вообще все перегруппированные .debug
> симлинки, имеющиеся в RPM_BUILD_ROOT.  Т.е. если симлинк libfoo.so вообще
> не запакован, но создан в билдруте, то симлинк libfoo.so.debug будет
> вписан в libfoo-debuginfo.
> 
> А в идеале бы надо паковать только те симлинки, для которых есть
> соответствующие симлинки в основном пакете - либо в libfoo, либо
> в libfoo-devel.
> 
> К сожалению это не так просто сделать, хотя и не очень сложно.
> Прототип реализации у меня был, но это требует некоторой поддержки
> со стороны librpmbuild.
> 
> > 2) debuginfo пакеты дают еще один метод чтобы выявить dll hell.
> > именно, foo слинковано с libA(v1) и libB, при чем libB
> > слинковано с libA(v2). 
> > Тогда foo-debuginfo не установится из-за файловых конфликтов между 
> > libA(v1)-debuginfo и libA(v2)-debuginfo.
> > 
> > если v1 > v2, то такую ситуацию, как я понимаю, должен
> > резать тест на устанавливаемость в incoming.
> > 
> > Вопрос: тест на устанавливаемость в incoming, он таки проверяет 
> > файловые конфликты?
> 
> Тест на устанавливаемость в incoming состоит в том, что каждый пакет,
> включая *-debuginfo, должен по отдельности устанавливаться в минимальную
> среду (basesystem).  Более "обширные" конфликты не проверяются.

т.е. если по зависимостям вытянутся пакеты с файловым конфликтом,
он не установится.

> > если v1 < v2, то такую ситуацию пока никто не отслеживает,
> > ее можно закрыть тестом repocop.
> 
> Кстати debuginfo пакеты дают ещё один метод проверки дублирования кода.
> 
> [at на people ~]$ fgrep /xmltok.c /ALT/Sisyphus/x86_64/base/contents_index
> /usr/src/debug/coin3d-3.1.3/src/xml/expat/xmltok.c	libcoin3d-debuginfo
> /usr/src/debug/expat-2.0.1/lib/xmltok.c	libexpat-debuginfo

Хозяйке на заметку. Где бы записать?
Кстати, что-то давно уже не публикуется старый метод,
отчеты о duplicate symbols.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine