[devel] Q: debuginfo strip controls & deps

[devel] Q: debuginfo strip controls & deps

[Alexey Tourbin]

Для окончательного внедрения 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.

Re: [devel] Q: debuginfo strip controls & deps

[Alexey Tourbin]

On Mon, Jan 31, 2011 at 09:58:04PM +0600, REAL wrote:
> 31.01.2011 21:23, Alexey Tourbin пишет:
> >Стадия brp-debuginfo заменяет brp-strip.  Макросы, 
> >которые задают
> >параметры для brp-strip, такие как %set_strip_method и
> >%add_strip_skiplist, не производят эффекта на 
> >brp-debuginfo.
> 
> а если необходим %set_strip_method shared? мне 
> бывает нужен для того, чтобы не стрипать 
> исполняемые файлы.

Почему _нужно_ не стрипать исполняемые файлы?  Работоспособность
исполняемого файла не должна зависеть от того, стрипнут он или нет.
А если требуется нужно именно отладочная информация, то она вынесена
в *-debuginfo пакет - всё логично.

> >Менее актуальные вопросы:
> >1) Нужны ли другие strip-макросы.
> 
> см. выше.

Обоснуйте.

Re: [devel] Q: debuginfo strip controls & deps

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 478 bytes --]

On Mon, Jan 31, 2011 at 06:23:37PM +0300, Alexey Tourbin wrote:
[...]
> Я знаю всего несколько пакетов, где действительно требуется
> специальный режим обрезания файлов: а именно, требуется сохранить .symtab.
> Один из таких пакетов - glibc.  Это делает вопрос насчет strip-макросов
> актуальным, т.к. glibc ложится в основу иерархии debuginfo зависимостей.

См. тж.
http://git.altlinux.org/gears/v/..git?p=valgrind.git;a=blob;f=valgrind/README_PACKAGERS


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Q: debuginfo strip controls & deps

[REAL]

31.01.2011 21:23, Alexey Tourbin пишет:
> Стадия brp-debuginfo заменяет brp-strip.  Макросы, которые задают
> параметры для brp-strip, такие как %set_strip_method и
> %add_strip_skiplist, не производят эффекта на brp-debuginfo.

а если необходим %set_strip_method shared? мне бывает нужен для того, 
чтобы не стрипать исполняемые файлы.

> Менее актуальные вопросы:
> 1) Нужны ли другие strip-макросы.

см. выше.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] Q: debuginfo strip controls & deps

[REAL]

31.01.2011 21:42, Alexey Tourbin пишет:
>> а если необходим %set_strip_method shared? мне
>> бывает нужен для того, чтобы не стрипать
>> исполняемые файлы.
>
> Почему _нужно_ не стрипать исполняемые файлы?  Работоспособность
> исполняемого файла не должна зависеть от того, стрипнут он или нет.

это вы апстриму объясните.

сы:
>>> 1) Нужны ли другие strip-макросы.
>>
>> см. выше.
>
> Обоснуйте.

потому что стриптуный не работает. и апстрим недвусмысленно об этом 
говорит. если он неправ, то вы можете побеседовать с ними сами, это 
которые вон там:
http://www.open-axiom.org/

я же в таких разборках участвовать не собираюсь. просто прямо говорю, 
что если сборочница ломает пакет, который чинить некому (кроме at@, 
который этого делать, видимо, не будет, хотя и знает, как), то на 
такую сборочницу нужно вешать блокер либо менять дистрибутив.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] Q: debuginfo strip controls & deps

[Afanasov Dmitry]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

On Mon, Jan 31, 2011 at 06:23:37PM +0300, Alexey Tourbin wrote:
> Нужно также понимать, что для создания полноценных debuginfo пакетов не
> следует обрезать файлы самостоятельно, а положиться на brp-debuginfo.
просьба сделать преключатель: обрезать с debuginfo информацией, обрезать
нахрен, не обрезать. а также skiplist для файлов/каталогов, где оставлять
как есть.

> /usr/lib/debug/usr/lib/libfoo.so.1 -> debug(libfoo.so.1)
> /usr/lib/debug/usr/lib64/libfoo.so.1 -> debug64(libfoo.so.1)
если зависимостям быть, то I like это.
-- 
 С уважением
 Афанасов Дмитрий

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Q: debuginfo strip controls & deps

[Alexey Tourbin]

On Mon, Jan 31, 2011 at 07:33:51PM +0300, Afanasov Dmitry wrote:
> On Mon, Jan 31, 2011 at 06:23:37PM +0300, Alexey Tourbin wrote:
> > Нужно также понимать, что для создания полноценных debuginfo пакетов не
> > следует обрезать файлы самостоятельно, а положиться на brp-debuginfo.
> просьба сделать преключатель: обрезать с debuginfo информацией, обрезать
> нахрен, не обрезать. а также skiplist для файлов/каталогов, где оставлять
> как есть.

Если оставлять как есть, то будет неполноценный debuginfo пакет,
потому что не будут скопированы исходники в /usr/src/debug.
Сейчас хочется ограничиться минимальным количеством опций.
Специальные режимы, если они действительно нужны, можно добавить потом.

Ещё должна произойти определенная смена стереотипов.  Раньше каждый
обрезал файлы как ему Бог на душу положит.  Например, в vim.spec
файлы обрезаются при установке с помощью макроса %strip_executable.
Зачем это делается, не понятно.  По крайней мере, особые свойства
/bin/vi по части ELF мне неизвестны.  Теперь же, чтобы получить
полноценные debuginfo пакеты, надо убрать всю отсебятину и подчиниться
процедуре brp-debuginfo.  Вклиниваться в brp-debuginfo можно только в том
случае, если слишком сильное обрезание влияет на работоспособность
пакетов.

> > /usr/lib/debug/usr/lib/libfoo.so.1 -> debug(libfoo.so.1)
> > /usr/lib/debug/usr/lib64/libfoo.so.1 -> debug64(libfoo.so.1)
> если зависимостям быть, то I like это.

Это во многом дело вкуса.  Мне тоже сначала нравилось.  С другой стороны,
обычные soname зависимости уже используют скобки.

Re: [devel] Q: debuginfo strip controls & deps

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2631 bytes --]

On Mon, Jan 31, 2011 at 06:23:37PM +0300, Alexey Tourbin wrote:
[...]
> Я знаю всего несколько пакетов, где действительно требуется
> специальный режим обрезания файлов: а именно, требуется сохранить .symtab.
> Один из таких пакетов - glibc.  Это делает вопрос насчет strip-макросов
> актуальным, т.к. glibc ложится в основу иерархии debuginfo зависимостей.

Попадаются ещё ELF'ы, которые предназначены для обработки нестандартными
загрузчиками, в т.ч. и не в userspace.  Вероятно, такие файлы лучше вообще
не трогать.  Видно, что сейчас в brp-debuginfo захардкодены исключения
/usr/share и /lib/firmware.  Я бы добавил туда ещё и /boot с /lib/modules.

> Предлагаю реализовать всего один новый strip-макрос - сохранение .symtab
> при обрезании -
> 	%название-макроса шелл-глоб
> Требуется придумать нвазвание макроса.
> Название может включать "keep_symtab" или "strip_debug_only".

strip_debug_only не вполне понятен, поскольку не очевидно, что есть
debug only.

Если смысл макроса в сохранении секции .symtab, то пусть лучше будет
%debuginfo_strip_keep_symtab shell-glob-pattern

> Актуальный вопрос №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)

Эти варианты не годятся, особенно первый из них, поскольку совпадают с
возможными обычными зависимостями на soname.

> Менее актуальные вопросы:
> 1) Нужны ли другие strip-макросы.

Видимо, нужно уметь отключать обработку отдельных файлов по причине
"мейнтейнеру виднее", например,
%debuginfo_skip_files shell-glob-pattern

> 2) Стоит ли обрезать lib*.a архивы.

До сих пор эти файлы не стрипались, но и -g до сих пор по умолчанию не
было.  Не очевидно.

> 3) Реорганизация репозитория - стоит ли делать RPMS.debug.

Число arch-пакетов практически удвоится -- как это скажется на индексах?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Q: debuginfo strip controls & deps

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 478 bytes --]

On Tue, Feb 01, 2011 at 12:46:04AM +0300, Dmitry V. Levin wrote:
> On Mon, Jan 31, 2011 at 06:23:37PM +0300, Alexey Tourbin wrote:
[...]
> > 2) Стоит ли обрезать lib*.a архивы.
> 
> До сих пор эти файлы не стрипались, но и -g до сих пор по умолчанию не
> было.  Не очевидно.

Размер файла /usr/lib64/librpm.a в alt100.15 вырос примерно в 5 раз по
сравнению с alt100.14; аналогичные показатели при пересборке
libssl-devel-static.  Какая от этого польза?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Q: debuginfo strip controls & deps

[Alexey Tourbin]

On Tue, Feb 01, 2011 at 02:33:50AM +0300, Dmitry V. Levin wrote:
> On Tue, Feb 01, 2011 at 12:46:04AM +0300, Dmitry V. Levin wrote:
> > On Mon, Jan 31, 2011 at 06:23:37PM +0300, Alexey Tourbin wrote:
> [...]
> > > 2) Стоит ли обрезать lib*.a архивы.
> > 
> > До сих пор эти файлы не стрипались, но и -g до сих пор по умолчанию не
> > было.  Не очевидно.
> 
> Размер файла /usr/lib64/librpm.a в alt100.15 вырос примерно в 5 раз по
> сравнению с alt100.14; аналогичные показатели при пересборке
> libssl-devel-static.  Какая от этого польза?

Польза интересная.  Когда мы подцепили lib*.a, то наконец-то появился ELF,
который будет обрабатываться в brp-debuginfo.  Там будут смотреть
$RPM_BUILD_DIR и заменять его на /usr/src/debug.  Если в lib*.a архиве есть
as-is ссылка на $RPM_BUILD_DIR, то после компоновки и brp-strip она будет
заменена на /usr/src/debug.

Происходит чудо, которое трудно объяснить в двух словах, производя
движения руками: после линковки с lib*.a архивам для отладки годятся
обычные lib*-debuginfo пакеты.

> -- 
> ldv

Re: [devel] Q: debuginfo strip controls & deps

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1356 bytes --]

On Tue, Feb 01, 2011 at 07:02:45AM +0300, Alexey Tourbin wrote:
> On Tue, Feb 01, 2011 at 02:33:50AM +0300, Dmitry V. Levin wrote:
> > On Tue, Feb 01, 2011 at 12:46:04AM +0300, Dmitry V. Levin wrote:
> > > On Mon, Jan 31, 2011 at 06:23:37PM +0300, Alexey Tourbin wrote:
> > [...]
> > > > 2) Стоит ли обрезать lib*.a архивы.
> > > 
> > > До сих пор эти файлы не стрипались, но и -g до сих пор по умолчанию не
> > > было.  Не очевидно.
> > 
> > Размер файла /usr/lib64/librpm.a в alt100.15 вырос примерно в 5 раз по
> > сравнению с alt100.14; аналогичные показатели при пересборке
> > libssl-devel-static.  Какая от этого польза?
> 
> Польза интересная.  Когда мы подцепили lib*.a, то наконец-то появился ELF,
> который будет обрабатываться в brp-debuginfo.  Там будут смотреть
> $RPM_BUILD_DIR и заменять его на /usr/src/debug.  Если в lib*.a архиве есть
> as-is ссылка на $RPM_BUILD_DIR, то после компоновки и brp-strip она будет
> заменена на /usr/src/debug.
> 
> Происходит чудо, которое трудно объяснить в двух словах, производя
> движения руками: после линковки с lib*.a архивам для отладки годятся
> обычные lib*-debuginfo пакеты.

При условии, что объектные файлы, которые попали в lib*.a, были
скомпилированы так же, как и объектные файлы, которые попали в lib*.so;
впрочем, обычно это условие не выполнено.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Q: debuginfo strip controls & deps

[Alexey Tourbin]

On Tue, Feb 01, 2011 at 12:29:38PM +0300, Dmitry V. Levin wrote:
> > Польза интересная.  Когда мы подцепили lib*.a, то наконец-то появился ELF,
> > который будет обрабатываться в brp-debuginfo.  Там будут смотреть
> > $RPM_BUILD_DIR и заменять его на /usr/src/debug.  Если в lib*.a архиве есть
> > as-is ссылка на $RPM_BUILD_DIR, то после компоновки и brp-strip она будет
> > заменена на /usr/src/debug.
> > 
> > Происходит чудо, которое трудно объяснить в двух словах, производя
> > движения руками: после линковки с lib*.a архивам для отладки годятся
> > обычные lib*-debuginfo пакеты.
> 
> При условии, что объектные файлы, которые попали в lib*.a, были
> скомпилированы так же, как и объектные файлы, которые попали в lib*.so;
> впрочем, обычно это условие не выполнено.

Исходники годятся в /usr/src/debug!
Если оба пакета собраны в хешере (с одинаковым $RPM_BUILD_DIR).

Re: [devel] Q: debuginfo strip controls & deps

[Alexey Tourbin]

On Mon, Jan 31, 2011 at 06:46:40PM +0300, Dmitry V. Levin wrote:
> On Mon, Jan 31, 2011 at 06:23:37PM +0300, Alexey Tourbin wrote:
> [...]
> > Я знаю всего несколько пакетов, где действительно требуется
> > специальный режим обрезания файлов: а именно, требуется сохранить .symtab.
> > Один из таких пакетов - glibc.  Это делает вопрос насчет strip-макросов
> > актуальным, т.к. glibc ложится в основу иерархии debuginfo зависимостей.
> 
> См. тж.
> http://git.altlinux.org/gears/v/..git?p=valgrind.git;a=blob;f=valgrind/README_PACKAGERS

Придумал два макроса - %brp_strip_debug и %brp_strip_none (по умолчанию
подразумевается --strip-all).

--- valgrind.spec-   2011-01-12
+++ valgrind.spec    2011-02-03
@@ -153,7 +153,7 @@ install -m644 -p AUTHORS FAQ.txt NEWS \
        %buildroot%_docdir/%name-%version/

 # Valgrind shared libraries should not be stripped - see README_PACKAGERS
-%set_strip_method executable
+%brp_strip_none %_libdir/%name/vgpreload*.so


 %files

Re: [devel] Q: debuginfo strip controls & deps

[REAL]

03.02.2011 15:20, Alexey Tourbin пишет:
> Придумал два макроса - %brp_strip_debug и %brp_strip_none (по умолчанию
> подразумевается --strip-all).
>
> --- valgrind.spec-   2011-01-12
> +++ valgrind.spec    2011-02-03
> @@ -153,7 +153,7 @@ install -m644 -p AUTHORS FAQ.txt NEWS \
>          %buildroot%_docdir/%name-%version/
>
>   # Valgrind shared libraries should not be stripped - see README_PACKAGERS
> -%set_strip_method executable
> +%brp_strip_none %_libdir/%name/vgpreload*.so

Т.е. в моём случае вместо
%set_strip_method shared
будет теперь
%brp_strip_none %_bindir/*

или я что-то не догнал?

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] Q: debuginfo strip controls & deps

[Alexey Tourbin]

On Thu, Feb 03, 2011 at 03:55:18PM +0600, REAL wrote:
> 03.02.2011 15:20, Alexey Tourbin пишет:
> >Придумал два макроса - %brp_strip_debug и 
> >%brp_strip_none (по умолчанию
> >подразумевается --strip-all).
> >
> >--- valgrind.spec-   2011-01-12
> >+++ valgrind.spec    2011-02-03
> >@@ -153,7 +153,7 @@ install -m644 -p AUTHORS FAQ.txt NEWS \
> >         %buildroot%_docdir/%name-%version/
> >
> >  # Valgrind shared libraries should not be stripped - see README_PACKAGERS
> >-%set_strip_method executable
> >+%brp_strip_none %_libdir/%name/vgpreload*.so
> 
> Т.е. в моём случае вместо
> %set_strip_method shared
> будет теперь
> %brp_strip_none %_bindir/*
> 
> или я что-то не догнал?

Если пакет раньше собирался без -g, что скорее всего, то 
%brp_strip_debug %_bindir/*
(то есть вместо --strip-all будет --strip-debug - отрезать только
отладочную информацию, которая появилась из-за компиляции с -g).

Если же файлы и раньше компилировались с -g, тогда для достижения старого
эффекта надо будет писать
%brp_strip_none %_bindir/*

Это ещё не совсем окончательный вариант, но скорее всего будет как-то так.

Re: [devel] Q: debuginfo strip controls & deps

[REAL]

03.02.2011 16:16, Alexey Tourbin пишет:
> Это ещё не совсем окончательный вариант, но скорее всего будет как-то так.

Надеюсь, когда всё устаканится, на wiki появится соответствующая 
информация, проанонсированная здесь ;)

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] Q: debuginfo strip controls & deps

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]

On Thu, Feb 03, 2011 at 12:20:34PM +0300, Alexey Tourbin wrote:
> On Mon, Jan 31, 2011 at 06:46:40PM +0300, Dmitry V. Levin wrote:
> > On Mon, Jan 31, 2011 at 06:23:37PM +0300, Alexey Tourbin wrote:
> > [...]
> > > Я знаю всего несколько пакетов, где действительно требуется
> > > специальный режим обрезания файлов: а именно, требуется сохранить .symtab.
> > > Один из таких пакетов - glibc.  Это делает вопрос насчет strip-макросов
> > > актуальным, т.к. glibc ложится в основу иерархии debuginfo зависимостей.
> > 
> > См. тж.
> > http://git.altlinux.org/gears/v/..git?p=valgrind.git;a=blob;f=valgrind/README_PACKAGERS
> 
> Придумал два макроса - %brp_strip_debug и %brp_strip_none (по умолчанию
> подразумевается --strip-all).
> 
> --- valgrind.spec-   2011-01-12
> +++ valgrind.spec    2011-02-03
> @@ -153,7 +153,7 @@ install -m644 -p AUTHORS FAQ.txt NEWS \
>         %buildroot%_docdir/%name-%version/
> 
>  # Valgrind shared libraries should not be stripped - see README_PACKAGERS
> -%set_strip_method executable
> +%brp_strip_none %_libdir/%name/vgpreload*.so

OK, тогда какой макрос предлагается использовать для
/lib64/ld-linux-x86-64.so.2 и подобных, где можно кое-что стрипать, но
вот как раз символы для отладки лучше не стрипать (см. тот же самый
valgrind/README_PACKAGERS)?

Или, может быть, стрипать эти файлы обычным образом, но запаковать
зависимость на glibc-core-debuginfo в gdb и valgrind?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Q: debuginfo strip controls & deps

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1727 bytes --]

On Fri, Feb 04, 2011 at 08:40:10PM +0300, Dmitry V. Levin wrote:
> On Thu, Feb 03, 2011 at 12:20:34PM +0300, Alexey Tourbin wrote:
> > On Mon, Jan 31, 2011 at 06:46:40PM +0300, Dmitry V. Levin wrote:
> > > On Mon, Jan 31, 2011 at 06:23:37PM +0300, Alexey Tourbin wrote:
> > > [...]
> > > > Я знаю всего несколько пакетов, где действительно требуется
> > > > специальный режим обрезания файлов: а именно, требуется сохранить .symtab.
> > > > Один из таких пакетов - glibc.  Это делает вопрос насчет strip-макросов
> > > > актуальным, т.к. glibc ложится в основу иерархии debuginfo зависимостей.
> > > 
> > > См. тж.
> > > http://git.altlinux.org/gears/v/..git?p=valgrind.git;a=blob;f=valgrind/README_PACKAGERS
> > 
> > Придумал два макроса - %brp_strip_debug и %brp_strip_none (по умолчанию
> > подразумевается --strip-all).
> > 
> > --- valgrind.spec-   2011-01-12
> > +++ valgrind.spec    2011-02-03
> > @@ -153,7 +153,7 @@ install -m644 -p AUTHORS FAQ.txt NEWS \
> >         %buildroot%_docdir/%name-%version/
> > 
> >  # Valgrind shared libraries should not be stripped - see README_PACKAGERS
> > -%set_strip_method executable
> > +%brp_strip_none %_libdir/%name/vgpreload*.so
> 
> OK, тогда какой макрос предлагается использовать для
> /lib64/ld-linux-x86-64.so.2 и подобных, где можно кое-что стрипать, но
> вот как раз символы для отладки лучше не стрипать (см. тот же самый
> valgrind/README_PACKAGERS)?
> 
> Или, может быть, стрипать эти файлы обычным образом, но запаковать
> зависимость на glibc-core-debuginfo в gdb и valgrind?

Я склоняюсь ко второму варианту.  Если у кого-то есть сомнения,
постарайтесь успеть их высказать до отправки glibc-2.11.3-alt3 на сборку.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Q: debuginfo strip controls & deps

[Alexey Tourbin]

On Fri, Feb 04, 2011 at 08:40:10PM +0300, Dmitry V. Levin wrote:
> > Придумал два макроса - %brp_strip_debug и %brp_strip_none (по умолчанию
> > подразумевается --strip-all).
> > 
> > --- valgrind.spec-   2011-01-12
> > +++ valgrind.spec    2011-02-03
> > @@ -153,7 +153,7 @@ install -m644 -p AUTHORS FAQ.txt NEWS \
> >         %buildroot%_docdir/%name-%version/
> > 
> >  # Valgrind shared libraries should not be stripped - see README_PACKAGERS
> > -%set_strip_method executable
> > +%brp_strip_none %_libdir/%name/vgpreload*.so
> 
> OK, тогда какой макрос предлагается использовать для
> /lib64/ld-linux-x86-64.so.2 и подобных, где можно кое-что стрипать, но
> вот как раз символы для отладки лучше не стрипать (см. тот же самый
> valgrind/README_PACKAGERS)?

%brp_strip_debug, название по аналогии с опцией strip --strip-debug.

> Или, может быть, стрипать эти файлы обычным образом, но запаковать
> зависимость на glibc-core-debuginfo в gdb и valgrind?

Я исходил из того, что если выделять отедльную компоненту репозитория
RPMS.debug, то компонента RPMS.classic должна остаться замкнутой.  То
есть предлагаю сделать, чтобы зависимости на *-debuginfo пакеты могли
быть только между самими *-debuginfo пакетами.

Re: [devel] Q: debuginfo strip controls & deps

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]

On Fri, Feb 04, 2011 at 11:38:19PM +0300, Alexey Tourbin wrote:
> On Fri, Feb 04, 2011 at 08:40:10PM +0300, Dmitry V. Levin wrote:
> > > Придумал два макроса - %brp_strip_debug и %brp_strip_none (по умолчанию
> > > подразумевается --strip-all).
> > > 
> > > --- valgrind.spec-   2011-01-12
> > > +++ valgrind.spec    2011-02-03
> > > @@ -153,7 +153,7 @@ install -m644 -p AUTHORS FAQ.txt NEWS \
> > >         %buildroot%_docdir/%name-%version/
> > > 
> > >  # Valgrind shared libraries should not be stripped - see README_PACKAGERS
> > > -%set_strip_method executable
> > > +%brp_strip_none %_libdir/%name/vgpreload*.so
> > 
> > OK, тогда какой макрос предлагается использовать для
> > /lib64/ld-linux-x86-64.so.2 и подобных, где можно кое-что стрипать, но
> > вот как раз символы для отладки лучше не стрипать (см. тот же самый
> > valgrind/README_PACKAGERS)?
> 
> %brp_strip_debug, название по аналогии с опцией strip --strip-debug.

Я уже посмотрел код и пришел к аналогичному выводу.

> > Или, может быть, стрипать эти файлы обычным образом, но запаковать
> > зависимость на glibc-core-debuginfo в gdb и valgrind?
> 
> Я исходил из того, что если выделять отедльную компоненту репозитория
> RPMS.debug, то компонента RPMS.classic должна остаться замкнутой.  То
> есть предлагаю сделать, чтобы зависимости на *-debuginfo пакеты могли
> быть только между самими *-debuginfo пакетами.

Согласен.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Q: debuginfo strip controls & deps

[Alexey Tourbin]

On Sat, Feb 05, 2011 at 01:21:50AM +0300, Dmitry V. Levin wrote:
> > %brp_strip_debug, название по аналогии с опцией strip --strip-debug.
> Я уже посмотрел код и пришел к аналогичному выводу.

Из крупных недоделок осталось доделать только коррекцию %{SIZE}.
Кажется, это не очень сложно.  Я отклчил тестовую i586-пересборку -
скорее всего, включу её через пару часов.

Re: [devel] Q: debuginfo strip controls & deps

[Alexey Tourbin]

On Sat, Feb 05, 2011 at 02:00:24AM +0300, Alexey Tourbin wrote:
> On Sat, Feb 05, 2011 at 01:21:50AM +0300, Dmitry V. Levin wrote:
> > > %brp_strip_debug, название по аналогии с опцией strip --strip-debug.
> > Я уже посмотрел код и пришел к аналогичному выводу.
> 
> Из крупных недоделок осталось доделать только коррекцию %{SIZE}.
> Кажется, это не очень сложно.  Я отклчил тестовую i586-пересборку -
> скорее всего, включу её через пару часов.

Отпарвил в сизиф rpm 4.0.4-alt100.16 с исправленным %{SIZE}, с debug64()
зависимостями и с оптимизатором зависимостей между подпакетами.  Запустил
тестовую пересборку.

2ldv: пожалуйста повнимательнее проверь как собралась glibc (напр. в
/tasks/38013/build/200/x86_64/rpms), всё ли тебе нравится.  Кстати,
кажется, оптимизированные под sse4.2 функции не подцепились.

[apiary@ssh rpms]$ rpmpeek glibc-core-2.11.3-alt3.x86_64.rpm readelf -aW ./lib64/libc.so.6 |fgrep strcmp
  2022: 000000000007a220  5289 FUNC    GLOBAL DEFAULT   12 strcmp@@GLIBC_2.2.5
[apiary@ssh rpms]$ rpmpeek glibc-core-2.11.3-alt3.x86_64.rpm readelf -aW ./lib64/libc.so.6 |fgrep strlen
   751: 000000000007bc40    69 FUNC    GLOBAL DEFAULT   12 strlen@@GLIBC_2.2.5
[apiary@ssh rpms]$ rpmpeek glibc-core-2.11.3-alt3.x86_64.rpm readelf -aW ./lib64/libc.so.6 |fgrep IFUNC
[apiary@ssh rpms]$

И ещё обрати внимание, что, кажется, на i586 эти функции должны
подцепиться через i686.

Насчет оптимизации зависимостей между подпакетами.  Мне совсем недавно
пришло в голову, что зависимости можно оптимизировать ещё сильнее:
а именно, оптимизировать можно не только зависимости, удовлетворённые
через Provides, но и зависимости, удовлетворенные через Requires! Ж-)

Пусть например пакет rpm требует две зависимости
librpm = 4.0.4-alt16
libc.so.6()(64bit)
а пакет librpm в свою очередь требует среди прочих зависимость
libc.so.6()(64bit)

Тогда из пакета rpm можно удалить зависимость на libc.so.6()(64bit).
То есть некоторые зависимости подпакетов иногда "отоваривать", как говорит
лидер нации, через базовый подпакет.  Что в принципе имеет смысл.

Но там сложнее сделать, поскольку две Requires зависимости нельзя
сравнивать напрямую.  И это не будет хорошо работать с set-версиями,
потому что обычно будут разные/несравнимые подможества.  А оптимизация
зависимостей делается прежде всего, чтобы снизить нагрузку на
pkglist/pkgcache и apt, которая подскочила из-за set-версий.

В общем пока не решил, делать ещё одну оптимизацию зависимостей или нет.
Предлагаю дождаться окончания i586-пересборки, чтобы оценить степень
разлома.  Потом можно решить, что нужно будет достаточно быстро доделать
или переделать.  Впрочем, glibc вроде бы можно собирать в любом случае.

Re: [devel] Q: debuginfo strip controls & deps

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2685 bytes --]

On Sat, Feb 05, 2011 at 08:41:03AM +0300, Alexey Tourbin wrote:
[...]
> 2ldv: пожалуйста повнимательнее проверь как собралась glibc (напр. в
> /tasks/38013/build/200/x86_64/rpms), всё ли тебе нравится.  Кстати,
> кажется, оптимизированные под sse4.2 функции не подцепились.

В спеке была опечатка.

> [apiary@ssh rpms]$ rpmpeek glibc-core-2.11.3-alt3.x86_64.rpm readelf -aW ./lib64/libc.so.6 |fgrep strcmp
>   2022: 000000000007a220  5289 FUNC    GLOBAL DEFAULT   12 strcmp@@GLIBC_2.2.5
> [apiary@ssh rpms]$ rpmpeek glibc-core-2.11.3-alt3.x86_64.rpm readelf -aW ./lib64/libc.so.6 |fgrep strlen
>    751: 000000000007bc40    69 FUNC    GLOBAL DEFAULT   12 strlen@@GLIBC_2.2.5
> [apiary@ssh rpms]$ rpmpeek glibc-core-2.11.3-alt3.x86_64.rpm readelf -aW ./lib64/libc.so.6 |fgrep IFUNC
> [apiary@ssh rpms]$

Будет так:
$ readelf -aW /lib64/libc.so.6 |fgrep IFUNC
    39: 0000000000085c50    55 IFUNC   WEAK   DEFAULT   12 strcasestr@@GLIBC_2.2.5
    90: 000000000007b8c0    41 IFUNC   GLOBAL DEFAULT   12 strcpy@@GLIBC_2.2.5
   100: 0000000000080d40    41 IFUNC   GLOBAL DEFAULT   12 __rawmemchr@@GLIBC_2.2.5
   173: 000000000007c090    60 IFUNC   GLOBAL DEFAULT   12 strncmp@@GLIBC_2.2.5
   216: 000000000007d950    41 IFUNC   GLOBAL DEFAULT   12 strrchr@@GLIBC_2.2.5
   309: 000000000007f920    41 IFUNC   WEAK   DEFAULT   12 stpncpy@@GLIBC_2.2.5
   387: 000000000007d920    41 IFUNC   GLOBAL DEFAULT   12 strncpy@@GLIBC_2.2.5
   518: 000000000007da20    41 IFUNC   GLOBAL DEFAULT   12 strpbrk@@GLIBC_2.2.5
   541: 000000000007ddb0    41 IFUNC   GLOBAL DEFAULT   12 strspn@@GLIBC_2.2.5
   602: 000000000007f920    41 IFUNC   GLOBAL DEFAULT   12 __stpncpy@@GLIBC_2.2.5
   751: 000000000007be80    41 IFUNC   GLOBAL DEFAULT   12 strlen@@GLIBC_2.2.5
   836: 00000000000848b0    55 IFUNC   GLOBAL DEFAULT   12 strstr@@GLIBC_2.2.5
   841: 000000000007b9d0    41 IFUNC   GLOBAL DEFAULT   12 strcspn@@GLIBC_2.2.5
  1219: 00000000000c3440    55 IFUNC   GLOBAL DEFAULT   12 __sched_cpucount@@GLIBC_2.6
  1401: 000000000007a310    41 IFUNC   WEAK   DEFAULT   12 index@@GLIBC_2.2.5
  1656: 000000000007a310    41 IFUNC   GLOBAL DEFAULT   12 strchr@@GLIBC_2.2.5
  1695: 000000000007d950    41 IFUNC   WEAK   DEFAULT   12 rindex@@GLIBC_2.2.5
  1718: 000000000007f810    41 IFUNC   GLOBAL DEFAULT   12 __stpcpy@@GLIBC_2.2.5
  1758: 0000000000085c50    55 IFUNC   GLOBAL DEFAULT   12 __strcasestr@@GLIBC_2.2.5
  1994: 0000000000080d40    41 IFUNC   GLOBAL DEFAULT   12 rawmemchr@@GLIBC_2.2.5
  2023: 000000000007a3c0    60 IFUNC   GLOBAL DEFAULT   12 strcmp@@GLIBC_2.2.5
  2055: 000000000007f810    41 IFUNC   WEAK   DEFAULT   12 stpcpy@@GLIBC_2.2.5


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Q: debuginfo strip controls & deps

[Alexey Tourbin]

On Sat, Feb 05, 2011 at 05:00:57PM +0300, Dmitry V. Levin wrote:
> Будет так:
> $ readelf -aW /lib64/libc.so.6 |fgrep IFUNC
>     39: 0000000000085c50    55 IFUNC   WEAK   DEFAULT   12 strcasestr@@GLIBC_2.2.5
>     90: 000000000007b8c0    41 IFUNC   GLOBAL DEFAULT   12 strcpy@@GLIBC_2.2.5
>    100: 0000000000080d40    41 IFUNC   GLOBAL DEFAULT   12 __rawmemchr@@GLIBC_2.2.5
>    173: 000000000007c090    60 IFUNC   GLOBAL DEFAULT   12 strncmp@@GLIBC_2.2.5
>    216: 000000000007d950    41 IFUNC   GLOBAL DEFAULT   12 strrchr@@GLIBC_2.2.5
>    309: 000000000007f920    41 IFUNC   WEAK   DEFAULT   12 stpncpy@@GLIBC_2.2.5
>    387: 000000000007d920    41 IFUNC   GLOBAL DEFAULT   12 strncpy@@GLIBC_2.2.5
>    518: 000000000007da20    41 IFUNC   GLOBAL DEFAULT   12 strpbrk@@GLIBC_2.2.5
>    541: 000000000007ddb0    41 IFUNC   GLOBAL DEFAULT   12 strspn@@GLIBC_2.2.5
>    602: 000000000007f920    41 IFUNC   GLOBAL DEFAULT   12 __stpncpy@@GLIBC_2.2.5
>    751: 000000000007be80    41 IFUNC   GLOBAL DEFAULT   12 strlen@@GLIBC_2.2.5
>    836: 00000000000848b0    55 IFUNC   GLOBAL DEFAULT   12 strstr@@GLIBC_2.2.5
>    841: 000000000007b9d0    41 IFUNC   GLOBAL DEFAULT   12 strcspn@@GLIBC_2.2.5
>   1219: 00000000000c3440    55 IFUNC   GLOBAL DEFAULT   12 __sched_cpucount@@GLIBC_2.6
>   1401: 000000000007a310    41 IFUNC   WEAK   DEFAULT   12 index@@GLIBC_2.2.5
>   1656: 000000000007a310    41 IFUNC   GLOBAL DEFAULT   12 strchr@@GLIBC_2.2.5
>   1695: 000000000007d950    41 IFUNC   WEAK   DEFAULT   12 rindex@@GLIBC_2.2.5
>   1718: 000000000007f810    41 IFUNC   GLOBAL DEFAULT   12 __stpcpy@@GLIBC_2.2.5
>   1758: 0000000000085c50    55 IFUNC   GLOBAL DEFAULT   12 __strcasestr@@GLIBC_2.2.5
>   1994: 0000000000080d40    41 IFUNC   GLOBAL DEFAULT   12 rawmemchr@@GLIBC_2.2.5
>   2023: 000000000007a3c0    60 IFUNC   GLOBAL DEFAULT   12 strcmp@@GLIBC_2.2.5
>   2055: 000000000007f810    41 IFUNC   WEAK   DEFAULT   12 stpcpy@@GLIBC_2.2.5

Интересно.  В этом списке есть strcmp, но нет memcmp.  Скорее всего,
strcmp будет работать даже быстрее, чем memcmp.  Так что нет смысла
заниматься оптипизацией и заменять strcmp на memcmp (когда длина строки
уже известна).

> 
> -- 
> ldv

Re: [devel] Q: debuginfo strip controls & deps

[Alexey Tourbin]

On Sat, Feb 05, 2011 at 08:41:03AM +0300, Alexey Tourbin wrote:
> В общем пока не решил, делать ещё одну оптимизацию зависимостей или нет.
> Предлагаю дождаться окончания i586-пересборки, чтобы оценить степень
> разлома.  Потом можно решить, что нужно будет достаточно быстро доделать
> или переделать.  Впрочем, glibc вроде бы можно собирать в любом случае.

Выглядит неплохо.

at@solemn ~ 8 $ sudo apt-get install openssl-debuginfo
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
  glibc-core-debuginfo libcrypto10-debuginfo libssl10-debuginfo
The following NEW packages will be installed:
  glibc-core-debuginfo libcrypto10-debuginfo libssl10-debuginfo openssl-debuginfo
0 upgraded, 4 newly installed, 0 removed and 0 not upgraded.
Need to get 7150kB of archives.
After unpacking 44.5MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 copy: x86_64/classic glibc-core-debuginfo 6:2.11.3-alt3 [4388kB]
Get:2 copy: x86_64/classic libcrypto10-debuginfo 1.0.0c-alt1 [1868kB]
Get:3 copy: x86_64/classic libssl10-debuginfo 1.0.0c-alt1 [427kB]
Get:4 copy: x86_64/classic openssl-debuginfo 1.0.0c-alt1 [468kB]
Fetched 7150kB in 12s (595kB/s)
Committing changes...
Preparing...                        ############################# [100%]
1: glibc-core-debuginfo             ############################# [ 25%]
2: libcrypto10-debuginfo            ############################# [ 50%]
3: libssl10-debuginfo               ############################# [ 75%]
4: openssl-debuginfo                ############################# [100%]
Running /usr/lib/rpm/posttrans-filetriggers
Done.
at@solemn ~ 8 $

Re: [devel] Q: debuginfo strip controls & deps

[Alexey Tourbin]

On Sat, Feb 05, 2011 at 08:41:03AM +0300, Alexey Tourbin wrote:
> Насчет оптимизации зависимостей между подпакетами.  Мне совсем недавно
> пришло в голову, что зависимости можно оптимизировать ещё сильнее:
> а именно, оптимизировать можно не только зависимости, удовлетворённые
> через Provides, но и зависимости, удовлетворенные через Requires! Ж-)
> 
> Пусть например пакет rpm требует две зависимости
> librpm = 4.0.4-alt16
> libc.so.6()(64bit)
> а пакет librpm в свою очередь требует среди прочих зависимость
> libc.so.6()(64bit)
> 
> Тогда из пакета rpm можно удалить зависимость на libc.so.6()(64bit).
> То есть некоторые зависимости подпакетов иногда "отоваривать", как говорит
> лидер нации, через базовый подпакет.  Что в принципе имеет смысл.
> 
> Но там сложнее сделать, поскольку две Requires зависимости нельзя
> сравнивать напрямую.  И это не будет хорошо работать с set-версиями,
> потому что обычно будут разные/несравнимые подможества.  А оптимизация
> зависимостей делается прежде всего, чтобы снизить нагрузку на
> pkglist/pkgcache и apt, которая подскочила из-за set-версий.
> 
> В общем пока не решил, делать ещё одну оптимизацию зависимостей или нет.
> Предлагаю дождаться окончания i586-пересборки, чтобы оценить степень
> разлома.  Потом можно решить, что нужно будет достаточно быстро доделать
> или переделать.  Впрочем, glibc вроде бы можно собирать в любом случае.

Выложил предварительную реализацию (в ней есть что исправить, но она уже
работает).  Вот пример оптимизации.

$ compare_packages -i -a --requires /home/at/RPM/RPMS/x86_64/xz-5.0.0-alt2.x86_64.rpm
--- /tmp/.private/at/compare_packages.g3rVQA50Yd/1      2011-02-06 04:58:51.643607248 +0300
+++ /tmp/.private/at/compare_packages.g3rVQA50Yd/2      2011-02-06 04:58:51.627608733 +0300
@@ -1,13 +1,8 @@
 /lib64/ld-linux-x86-64.so.2
-libc.so.6(GLIBC_2.2.5)(64bit)
 libc.so.6(GLIBC_2.3)(64bit)
 libc.so.6(GLIBC_2.3.4)(64bit)
-libc.so.6(GLIBC_2.4)(64bit)
 libc.so.6(GLIBC_2.6)(64bit)
 libc.so.6(GLIBC_2.7)(64bit)
 liblzma = 5.0.0-alt2
-liblzma.so.5()(64bit) >= set:keZ91URZaAr4qmA33KZiAIxjIAjEn7NatiLJUn4TV4uFJQi2NM3bXAi8wGbUJG9kZz4dcZuysjASmPqbf13FsMl0
 libpthread.so.0(GLIBC_2.2.5)(64bit)
 rpmlib(PayloadIsLzma)
-rpmlib(SetVersions)
-rtld(GNU_HASH)
$

Здесь по первому правилу, которое уже реализовано, удаляется зависимость
на liblzma.so.5()(64bit) - т.к. пакет liblzma УДОВЛЕТВОРЯЕТ эту зависимость.

А остальные зависимости удалены по новому правилу - подпакет liblzma
УЖЕ ТРЕБУЕТ эти зависимости. Интересно, что rpmlib(PayloadIsLzma) не
удаляется - эта зависимость добавляется в самом конце (прямо перед записью
пакета на диск).

Re: [devel] Q: debuginfo strip controls & deps

[Alexey Tourbin]

On Sat, Feb 05, 2011 at 05:00:57PM +0300, Dmitry V. Levin wrote:
> Будет так:
> $ readelf -aW /lib64/libc.so.6 |fgrep IFUNC
>     39: 0000000000085c50    55 IFUNC   WEAK   DEFAULT   12 strcasestr@@GLIBC_2.2.5
>     90: 000000000007b8c0    41 IFUNC   GLOBAL DEFAULT   12 strcpy@@GLIBC_2.2.5
>    100: 0000000000080d40    41 IFUNC   GLOBAL DEFAULT   12 __rawmemchr@@GLIBC_2.2.5
>    173: 000000000007c090    60 IFUNC   GLOBAL DEFAULT   12 strncmp@@GLIBC_2.2.5
>    216: 000000000007d950    41 IFUNC   GLOBAL DEFAULT   12 strrchr@@GLIBC_2.2.5
>    309: 000000000007f920    41 IFUNC   WEAK   DEFAULT   12 stpncpy@@GLIBC_2.2.5
>    387: 000000000007d920    41 IFUNC   GLOBAL DEFAULT   12 strncpy@@GLIBC_2.2.5
>    518: 000000000007da20    41 IFUNC   GLOBAL DEFAULT   12 strpbrk@@GLIBC_2.2.5
>    541: 000000000007ddb0    41 IFUNC   GLOBAL DEFAULT   12 strspn@@GLIBC_2.2.5
>    602: 000000000007f920    41 IFUNC   GLOBAL DEFAULT   12 __stpncpy@@GLIBC_2.2.5
>    751: 000000000007be80    41 IFUNC   GLOBAL DEFAULT   12 strlen@@GLIBC_2.2.5
>    836: 00000000000848b0    55 IFUNC   GLOBAL DEFAULT   12 strstr@@GLIBC_2.2.5
>    841: 000000000007b9d0    41 IFUNC   GLOBAL DEFAULT   12 strcspn@@GLIBC_2.2.5
>   1219: 00000000000c3440    55 IFUNC   GLOBAL DEFAULT   12 __sched_cpucount@@GLIBC_2.6
>   1401: 000000000007a310    41 IFUNC   WEAK   DEFAULT   12 index@@GLIBC_2.2.5
>   1656: 000000000007a310    41 IFUNC   GLOBAL DEFAULT   12 strchr@@GLIBC_2.2.5
>   1695: 000000000007d950    41 IFUNC   WEAK   DEFAULT   12 rindex@@GLIBC_2.2.5
>   1718: 000000000007f810    41 IFUNC   GLOBAL DEFAULT   12 __stpcpy@@GLIBC_2.2.5
>   1758: 0000000000085c50    55 IFUNC   GLOBAL DEFAULT   12 __strcasestr@@GLIBC_2.2.5
>   1994: 0000000000080d40    41 IFUNC   GLOBAL DEFAULT   12 rawmemchr@@GLIBC_2.2.5
>   2023: 000000000007a3c0    60 IFUNC   GLOBAL DEFAULT   12 strcmp@@GLIBC_2.2.5
>   2055: 000000000007f810    41 IFUNC   WEAK   DEFAULT   12 stpcpy@@GLIBC_2.2.5

На i586 так и не подцепилось.  Там наверное хак надо делать -
скопировать некоторые файлы из i686 в i586 или что-нибудь такое.

$ rpmpeek /ALT/Sisyphus/files/i586/RPMS/glibc-core-2.11.3-alt3.i586.rpm readelf -aW ./lib/libc.so.6 |grep strlen
   807: 000740f0   187 FUNC    GLOBAL DEFAULT   12 strlen@@GLIBC_2.0
   937: 0007b220    23 FUNC    GLOBAL DEFAULT   12 __strlen_g@@GLIBC_2.1.1
$ rpmpeek /ALT/Sisyphus/files/i586/RPMS/glibc-core-2.11.3-alt3.i586.rpm readelf -aW ./lib/libc.so.6 |grep IFUNC
$ 

Re: [devel] Q: debuginfo strip controls & deps

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

On Sun, Feb 06, 2011 at 01:01:05PM +0300, Alexey Tourbin wrote:
[...]
> На i586 так и не подцепилось.  Там наверное хак надо делать -
> скопировать некоторые файлы из i686 в i586 или что-нибудь такое.
> 
> $ rpmpeek /ALT/Sisyphus/files/i586/RPMS/glibc-core-2.11.3-alt3.i586.rpm readelf -aW ./lib/libc.so.6 |grep strlen
>    807: 000740f0   187 FUNC    GLOBAL DEFAULT   12 strlen@@GLIBC_2.0
>    937: 0007b220    23 FUNC    GLOBAL DEFAULT   12 __strlen_g@@GLIBC_2.1.1
> $ rpmpeek /ALT/Sisyphus/files/i586/RPMS/glibc-core-2.11.3-alt3.i586.rpm readelf -aW ./lib/libc.so.6 |grep IFUNC

Я думаю, что для i586 эта фича не горит.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Q: debuginfo strip controls & deps

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 3035 bytes --]

On Sun, Feb 06, 2011 at 05:05:00AM +0300, Alexey Tourbin wrote:
> On Sat, Feb 05, 2011 at 08:41:03AM +0300, Alexey Tourbin wrote:
> > Насчет оптимизации зависимостей между подпакетами.  Мне совсем недавно
> > пришло в голову, что зависимости можно оптимизировать ещё сильнее:
> > а именно, оптимизировать можно не только зависимости, удовлетворённые
> > через Provides, но и зависимости, удовлетворенные через Requires! Ж-)
> > 
> > Пусть например пакет rpm требует две зависимости
> > librpm = 4.0.4-alt16
> > libc.so.6()(64bit)
> > а пакет librpm в свою очередь требует среди прочих зависимость
> > libc.so.6()(64bit)
> > 
> > Тогда из пакета rpm можно удалить зависимость на libc.so.6()(64bit).
> > То есть некоторые зависимости подпакетов иногда "отоваривать", как говорит
> > лидер нации, через базовый подпакет.  Что в принципе имеет смысл.
> > 
> > Но там сложнее сделать, поскольку две Requires зависимости нельзя
> > сравнивать напрямую.  И это не будет хорошо работать с set-версиями,
> > потому что обычно будут разные/несравнимые подможества.  А оптимизация
> > зависимостей делается прежде всего, чтобы снизить нагрузку на
> > pkglist/pkgcache и apt, которая подскочила из-за set-версий.
> > 
> > В общем пока не решил, делать ещё одну оптимизацию зависимостей или нет.
> > Предлагаю дождаться окончания i586-пересборки, чтобы оценить степень
> > разлома.  Потом можно решить, что нужно будет достаточно быстро доделать
> > или переделать.  Впрочем, glibc вроде бы можно собирать в любом случае.
> 
> Выложил предварительную реализацию (в ней есть что исправить, но она уже
> работает).  Вот пример оптимизации.
> 
> $ compare_packages -i -a --requires /home/at/RPM/RPMS/x86_64/xz-5.0.0-alt2.x86_64.rpm
> --- /tmp/.private/at/compare_packages.g3rVQA50Yd/1      2011-02-06 04:58:51.643607248 +0300
> +++ /tmp/.private/at/compare_packages.g3rVQA50Yd/2      2011-02-06 04:58:51.627608733 +0300
> @@ -1,13 +1,8 @@
>  /lib64/ld-linux-x86-64.so.2
> -libc.so.6(GLIBC_2.2.5)(64bit)
>  libc.so.6(GLIBC_2.3)(64bit)
>  libc.so.6(GLIBC_2.3.4)(64bit)
> -libc.so.6(GLIBC_2.4)(64bit)
>  libc.so.6(GLIBC_2.6)(64bit)
>  libc.so.6(GLIBC_2.7)(64bit)
>  liblzma = 5.0.0-alt2
> -liblzma.so.5()(64bit) >= set:keZ91URZaAr4qmA33KZiAIxjIAjEn7NatiLJUn4TV4uFJQi2NM3bXAi8wGbUJG9kZz4dcZuysjASmPqbf13FsMl0
>  libpthread.so.0(GLIBC_2.2.5)(64bit)
>  rpmlib(PayloadIsLzma)
> -rpmlib(SetVersions)
> -rtld(GNU_HASH)
> $
> 
> Здесь по первому правилу, которое уже реализовано, удаляется зависимость
> на liblzma.so.5()(64bit) - т.к. пакет liblzma УДОВЛЕТВОРЯЕТ эту зависимость.
> 
> А остальные зависимости удалены по новому правилу - подпакет liblzma
> УЖЕ ТРЕБУЕТ эти зависимости. Интересно, что rpmlib(PayloadIsLzma) не
> удаляется - эта зависимость добавляется в самом конце (прямо перед записью
> пакета на диск).

Важно отметить для тех, кто читает тред по диагонали, что такая оптимизация
легальна только потому, что пакеты liblzma и xz собираются из одного
исходного пакета.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Q: debuginfo strip controls & deps

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 3332 bytes --]

On Mon, Feb 07, 2011 at 12:22:09AM +0300, Dmitry V. Levin wrote:
> On Sun, Feb 06, 2011 at 05:05:00AM +0300, Alexey Tourbin wrote:
> > On Sat, Feb 05, 2011 at 08:41:03AM +0300, Alexey Tourbin wrote:
> > > Насчет оптимизации зависимостей между подпакетами.  Мне совсем недавно
> > > пришло в голову, что зависимости можно оптимизировать ещё сильнее:
> > > а именно, оптимизировать можно не только зависимости, удовлетворённые
> > > через Provides, но и зависимости, удовлетворенные через Requires! Ж-)
> > > 
> > > Пусть например пакет rpm требует две зависимости
> > > librpm = 4.0.4-alt16
> > > libc.so.6()(64bit)
> > > а пакет librpm в свою очередь требует среди прочих зависимость
> > > libc.so.6()(64bit)
> > > 
> > > Тогда из пакета rpm можно удалить зависимость на libc.so.6()(64bit).
> > > То есть некоторые зависимости подпакетов иногда "отоваривать", как говорит
> > > лидер нации, через базовый подпакет.  Что в принципе имеет смысл.
> > > 
> > > Но там сложнее сделать, поскольку две Requires зависимости нельзя
> > > сравнивать напрямую.  И это не будет хорошо работать с set-версиями,
> > > потому что обычно будут разные/несравнимые подможества.  А оптимизация
> > > зависимостей делается прежде всего, чтобы снизить нагрузку на
> > > pkglist/pkgcache и apt, которая подскочила из-за set-версий.
> > > 
> > > В общем пока не решил, делать ещё одну оптимизацию зависимостей или нет.
> > > Предлагаю дождаться окончания i586-пересборки, чтобы оценить степень
> > > разлома.  Потом можно решить, что нужно будет достаточно быстро доделать
> > > или переделать.  Впрочем, glibc вроде бы можно собирать в любом случае.
> > 
> > Выложил предварительную реализацию (в ней есть что исправить, но она уже
> > работает).  Вот пример оптимизации.
> > 
> > $ compare_packages -i -a --requires /home/at/RPM/RPMS/x86_64/xz-5.0.0-alt2.x86_64.rpm
> > --- /tmp/.private/at/compare_packages.g3rVQA50Yd/1      2011-02-06 04:58:51.643607248 +0300
> > +++ /tmp/.private/at/compare_packages.g3rVQA50Yd/2      2011-02-06 04:58:51.627608733 +0300
> > @@ -1,13 +1,8 @@
> >  /lib64/ld-linux-x86-64.so.2
> > -libc.so.6(GLIBC_2.2.5)(64bit)
> >  libc.so.6(GLIBC_2.3)(64bit)
> >  libc.so.6(GLIBC_2.3.4)(64bit)
> > -libc.so.6(GLIBC_2.4)(64bit)
> >  libc.so.6(GLIBC_2.6)(64bit)
> >  libc.so.6(GLIBC_2.7)(64bit)
> >  liblzma = 5.0.0-alt2
> > -liblzma.so.5()(64bit) >= set:keZ91URZaAr4qmA33KZiAIxjIAjEn7NatiLJUn4TV4uFJQi2NM3bXAi8wGbUJG9kZz4dcZuysjASmPqbf13FsMl0
> >  libpthread.so.0(GLIBC_2.2.5)(64bit)
> >  rpmlib(PayloadIsLzma)
> > -rpmlib(SetVersions)
> > -rtld(GNU_HASH)
> > $
> > 
> > Здесь по первому правилу, которое уже реализовано, удаляется зависимость
> > на liblzma.so.5()(64bit) - т.к. пакет liblzma УДОВЛЕТВОРЯЕТ эту зависимость.
> > 
> > А остальные зависимости удалены по новому правилу - подпакет liblzma
> > УЖЕ ТРЕБУЕТ эти зависимости. Интересно, что rpmlib(PayloadIsLzma) не
> > удаляется - эта зависимость добавляется в самом конце (прямо перед записью
> > пакета на диск).
> 
> Важно отметить для тех, кто читает тред по диагонали, что такая оптимизация
> легальна только потому, что пакеты liblzma и xz собираются из одного
> исходного пакета.

Хотя на самом деле она легальна потому, что у пакета xz есть _жесткая_
зависимость liblzma = 5.0.0-alt2.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]