From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 31 Jan 2011 18:23:37 +0300 From: Alexey Tourbin To: devel@lists.altlinux.org Message-ID: <20110131152337.GO30604@altlinux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: 8bit Subject: [devel] Q: debuginfo strip controls & deps X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 15:23:38 -0000 Archived-At: List-Archive: List-Post: Для окончательного внедрения debuginfo пакетов нужно решить два актуальных вопроса и несколько менее актуальных вопрос. Актуальный вопрос №1: strip-макросы. Стадия brp-debuginfo заменяет brp-strip. Макросы, которые задают параметры для brp-strip, такие как %set_strip_method и %add_strip_skiplist, не производят эффекта на brp-debuginfo. Более того, с появлением debuginfo пакетов старые макросы не подходят уже и по смыслу. Дело в том, что раньше пакеты собирались без -g, и поэтому, например, использование %add_strip_skiplist подразумевало, что файлы не содержат дополнительной отладочной информации (DWARF). Теперь же -g всегда используется в %optflags, а дополнительная отладочная информация может занимать очень много места (особенно в случае Си+плюс кода). По-видимому, дополнительную отладочную информацию надо обрезать в любом случае. Поэтому макросы типа %add_strip_skiplist уже не могут иметь прежний смысл. Нужно также понимать, что для создания полноценных debuginfo пакетов не следует обрезать файлы самостоятельно, а положиться на brp-debuginfo. Я знаю всего несколько пакетов, где действительно требуется специальный режим обрезания файлов: а именно, требуется сохранить .symtab. Один из таких пакетов - glibc. Это делает вопрос насчет strip-макросов актуальным, т.к. glibc ложится в основу иерархии debuginfo зависимостей. Предлагаю реализовать всего один новый strip-макрос - сохранение .symtab при обрезании - %название-макроса шелл-глоб Требуется придумать нвазвание макроса. Название может включать "keep_symtab" или "strip_debug_only". Актуальный вопрос №2: вид soname-зависимостей между debuginfo-пакетами. Сонейм-зависимости между основными пакетами имеют вид /usr/lib/libfoo.so.1 -> libfoo.so.1 /usr/lib64/libfoo.so.1 -> libfoo.so.1()(64bit) Для debuginfo пакетов будет создана иерархия зависимостей, похожая на основную, на основе сонеймов. Требуется придумать вид зависимостей для для сонеймов (ABI-интерфейсы использоваться не будут). Варианты могут быть такие: /usr/lib/debug/usr/lib/libfoo.so.1 -> debug(libfoo.so.1) /usr/lib/debug/usr/lib64/libfoo.so.1 -> debug64(libfoo.so.1) /usr/lib/debug/usr/lib/libfoo.so.1.debug -> libfoo.so.1.debug /usr/lib/debug/usr/lib64/libfoo.so.1.debug -> libfoo.so.1.debug()(64bit) /usr/lib/debug/usr/lib/libfoo.so.1.debug -> D-libfoo.so.1 /usr/lib/debug/usr/lib64/libfoo.so.1.debug -> D-libfoo.so.1()(64bit) Менее актуальные вопросы: 1) Нужны ли другие strip-макросы. 2) Стоит ли обрезать lib*.a архивы. 3) Реорганизация репозитория - стоит ли делать RPMS.debug.