[devel] strip

[devel] strip

[aen]

Уважаемые господа, напоминаю Вам (и себе еще раз) о необходимсоти читать
знаменитое README.ipl в документации к rpm :-)
Мне хотелось бы еще раз поднять проблему strip. Сейчас, по умолчанию, с
библиотеками эта поерация не проводится вообще. Началось это с моих
проблем при сборке XFree, где ни в коем случае нельзя делать простой
strip с модулями.
В то же время, нынешнее решение мне представляется неудобным. Не стоит
ли вернуться к прежней умалчиваемй ситуации, использовав то, что есть
сейчас у MDK и RH, но оставив возможность задавать методы strip вручную.
Хорошо бы также иметь параметры скриптов, позволяющие указать корень, от
которого идет strip.

Rgrds, Алексей.
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] strip

[Dmitry V. Levin]

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

On Wed, Dec 13, 2000 at 09:31:34PM +0300, aen wrote:
> Уважаемые господа, напоминаю Вам (и себе еще раз) о необходимсоти читать
> знаменитое README.ipl в документации к rpm :-)
> Мне хотелось бы еще раз поднять проблему strip. Сейчас, по умолчанию, с
> библиотеками эта поерация не проводится вообще. Началось это с моих
> проблем при сборке XFree, где ни в коем случае нельзя делать простой
> strip с модулями.
> В то же время, нынешнее решение мне представляется неудобным. Не стоит
> ли вернуться к прежней умалчиваемй ситуации, использовав то, что есть
> сейчас у MDK и RH, но оставив возможность задавать методы strip вручную.
> Хорошо бы также иметь параметры скриптов, позволяющие указать корень, от
> которого идет strip.

Цитирую сообщение полностью, в надежде, что Алексей прочтет его еще раз,
после чего прочтет пункт 4 в вышеупомянутом README.ipl, а также
дополнительную информацию, способ получения которой указан в последней
строке этого пункта.

Если что-то в документации не достаточно ясно написано, спрашивайте.
Но когда вопрос задается в форме, выдающей невнимательное чтение
документации автором вопроса, становится очень обидно; для программиста
сопровождение всегда дается сложнее, чем собственно программирование.

По поводу деталей policy: реализация в /usr/lib/rpm/brp-strip.

Вы предлагаете изменить значение макроса _strip_method с нынешнего
значения по-умолчанию (executable) на новое, добавив туда что-то из списка
relocatable, shared, static? Хорошо, но по каким причинам? Нехватка места
на CD? И что именно добавлять будем?

В конечном итоге, незачем менять умолчание в /usr/lib/rpm/macros;
достаточно изменить свои собственные настройки!


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@fandra.org
Software Engineer   PGP pubkey http://www.fandra.org/users/ldv/pgpkeys.html
IPLabs Linux Team   http://linux.iplabs.ru
Fandra Project      http://www.fandra.org
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who its friends are.

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

Re: [devel] strip

[Ivan Zakharyaschev]

Я, наверное, не вовремя с этим лезу, так что можно проигнорировать:

нельзя ли как-нибудь обобщить brp-compress так, чтобы он сжимал не только
документацию, но и файлы другого указанного типа в указанной packager'ом
директории? И позволить вызывать его на стадии %install.

Пример: так можно было бы сжимать данные для console-tools (раскладки,
шрифты). Файлы небольшие, но их много, и, как я убедился, gzip и bzip2 на
них работают с переменным успехом (зависит еще от того, бинарный файл или
текстовый). Сами console-tools умеют с обоими форматами работать (и не
только).

-- 
Best regards,
      Ivan Z.

_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] strip

[Ivan Zakharyaschev]

On Wed, 13 Dec 2000, Ivan Zakharyaschev wrote:

> Я, наверное, не вовремя с этим лезу, так что можно проигнорировать:
>
> нельзя ли как-нибудь обобщить brp-compress так, чтобы он сжимал не
> только
> документацию, но и файлы другого указанного типа в указанной
> packager'ом
> директории? И позволить вызывать его на стадии %install.

Или специальной директивой в разделе %files.

> Пример: так можно было бы сжимать данные для console-tools (раскладки,
> шрифты). Файлы небольшие, но их много, и, как я убедился, gzip и bzip2
> на
> них работают с переменным успехом (зависит еще от того, бинарный файл
> или

Недоговорил, что на man-pages они похожи еще и тем, что уже сжимаются на
стадии сборки, только все одним методом.

> текстовый). Сами console-tools умеют с обоими форматами работать (и не
> только).

-- 
Best regards,
      Ivan Z.

_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] strip

[Dmitry V. Levin]

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

On Wed, Dec 13, 2000 at 09:32:17PM +0300, Ivan Zakharyaschev wrote:
> > Я, наверное, не вовремя с этим лезу, так что можно проигнорировать:
> >
> > нельзя ли как-нибудь обобщить brp-compress так, чтобы он сжимал не
> > только
> > документацию, но и файлы другого указанного типа в указанной
> > packager'ом
> > директории? И позволить вызывать его на стадии %install.
> 
> Или специальной директивой в разделе %files.
> 
> > Пример: так можно было бы сжимать данные для console-tools (раскладки,
> > шрифты). Файлы небольшие, но их много, и, как я убедился, gzip и bzip2
> > на
> > них работают с переменным успехом (зависит еще от того, бинарный файл
> > или
> 
> Недоговорил, что на man-pages они похожи еще и тем, что уже сжимаются на
> стадии сборки, только все одним методом.
> 
> > текстовый). Сами console-tools умеют с обоими форматами работать (и не
> > только).

В данный момент /usr/lib/rpm/brp-compress рассчитан только на info и
manpages; конкретнее, этот скрипт находит и пакует эти файлы согласно
указанному/выбранному методу, и правит символические ссылки на них.

Специальная директива в секции %files - дело не для ближайшего будущего, а
вот возможность вызывать скрипт сжатия файлов вручную надо будет
предусмотреть. Вопрос только в синтаксисе: как будем объяснять программе,
что сжимать?


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@fandra.org
Software Engineer   PGP pubkey http://www.fandra.org/users/ldv/pgpkeys.html
IPLabs Linux Team   http://linux.iplabs.ru
Fandra Project      http://www.fandra.org
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who its friends are.

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

Re: [devel] strip

[Ivan Zakharyaschev]

On Thu, 14 Dec 2000, Dmitry V. Levin wrote:

> On Wed, Dec 13, 2000 at 09:32:17PM +0300, Ivan Zakharyaschev wrote:
> > > Я, наверное, не вовремя с этим лезу, так что можно проигнорировать:
> > >
> > > нельзя ли как-нибудь обобщить brp-compress так, чтобы он сжимал не
> > > только
> > > документацию, но и файлы другого указанного типа в указанной
> > > packager'ом
> > > директории? И позволить вызывать его на стадии %install.
> >
> > Или специальной директивой в разделе %files.
> >
> > > Пример: так можно было бы сжимать данные для console-tools
> (раскладки,
> > > шрифты). Файлы небольшие, но их много, и, как я убедился, gzip и

> > Недоговорил, что на man-pages они похожи еще и тем, что уже сжимаются
> на
> > стадии сборки, только все одним методом.

При вызове указывать директории, внутри которых производить пересжатие.
Директория пусть просматривается рекурсивно. Ну и обратываются только уже
сжатые файлы -- так, по-моему, проще: больше ясности. Пока можно
ограничиться этим. Без других конкретных примеров сейчас трудно
придумывать. Обычно такие данные (которых много в небольших файлах)
отделяются от остальных файлов на уровне каталогов.

> > > текстовый). Сами console-tools умеют с обоими форматами работать (и
> не
> > > только).

Я задался вопросом, стоит ли в пакеты, с такими сжатыми файлами добавлять
зависимость от gzip, bzip2 (какой толк от этих файлов, если их нечем
распаковать?).  По-моему, автоматически делать этого не стоит. И в виде
опции для autoreq такая возможность тоже довольно бессмыслена.

> В данный момент /usr/lib/rpm/brp-compress рассчитан
только на info и
> manpages; конкретнее, этот скрипт находит и пакует эти файлы согласно
> указанному/выбранному методу, и правит символические ссылки на них.
>
> Специальная директива в секции %files - дело не для ближайшего
> будущего, а
> вот возможность вызывать скрипт сжатия файлов вручную надо будет
> предусмотреть. Вопрос только в синтаксисе: как будем объяснять
> программе,
> что сжимать?

-- 
Best regards,
      Ivan Z.

_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] strip

[Mikhail Zabaluev]

Hello Ivan,

On Thu, Dec 14, 2000 at 19:43 +0300, Ivan Zakharyaschev wrote:
>
> On Thu, 14 Dec 2000, Dmitry V. Levin wrote:
> 
> > On Wed, Dec 13, 2000 at 09:32:17PM +0300, Ivan Zakharyaschev wrote:
> > > > Я, наверное, не вовремя с этим лезу, так что можно проигнорировать:
> > > >
> > > > нельзя ли как-нибудь обобщить brp-compress так, чтобы он сжимал не
> > > > только
> > > > документацию, но и файлы другого указанного типа в указанной
> > > > packager'ом
> > > > директории? И позволить вызывать его на стадии %install.
> > >
> > > Или специальной директивой в разделе %files.
> > >
> > > > Пример: так можно было бы сжимать данные для console-tools
> > (раскладки,
> > > > шрифты). Файлы небольшие, но их много, и, как я убедился, gzip и
> 
> > > Недоговорил, что на man-pages они похожи еще и тем, что уже сжимаются
> > на
> > > стадии сборки, только все одним методом.
> 
> При вызове указывать директории, внутри которых производить пересжатие.
> Директория пусть просматривается рекурсивно.

Может, лучше пусть будут shell globs? Редко когда такие файлы лежат на
разных уровнях дерева каталогов. И потенциально в будущем, для
спецатрибута в %files, globs будут адаптироваться естественно.

-- 
Stay tuned,
  MhZ                                    mailto:mookid@sigent.ru
-----------
malpractice, n.:
	The reason surgeons wear masks.
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] strip

[Ivan Zakharyaschev]

	Hello!

On Fri, 15 Dec 2000, Mikhail Zabaluev wrote:

> On Thu, Dec 14, 2000 at 19:43 +0300, Ivan Zakharyaschev wrote:
> >
> > On Thu, 14 Dec 2000, Dmitry V. Levin wrote:
> >
> > > On Wed, Dec 13, 2000 at 09:32:17PM +0300, Ivan Zakharyaschev wrote:

> > > > > нельзя ли как-нибудь обобщить brp-compress так, чтобы он сжимал
> не
> > > > > только
> > > > > документацию, но и файлы другого указанного типа в указанной
> > > > > packager'ом
> > > > > директории? И позволить вызывать его на стадии %install.

> > > > > Пример: так можно было бы сжимать данные для console-tools
> > > (раскладки,
> > > > > шрифты). Файлы небольшие, но их много, и, как я убедился, gzip

> > При вызове указывать директории, внутри которых производить
> пересжатие.
> > Директория пусть просматривается рекурсивно.
>
> Может, лучше пусть будут shell globs? Редко когда такие файлы лежат на
> разных уровнях дерева каталогов. И потенциально в будущем, для
> спецатрибута в %files, globs будут адаптироваться естественно.

Да, уровень обычно один, но я хотел сделать как проще, а писать просто имя
верхней директории проще, чем писать его и еще думать о том, сколько
слэш-звездочек добавить в конец. Кстати, в /usr/share/man/ страницы не все
лежат на одном уровне: есть еще переводы. Можно сделать shell globs с
рекурсивной обработкой.

-- 
Best regards,
      Ivan Z.

_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] strip

[Mikhail Zabaluev]

Hello Ivan,

On Wed, Dec 13, 2000 at 21:15 +0300, Ivan Zakharyaschev wrote:
>
> Я, наверное, не вовремя с этим лезу, так что можно проигнорировать:
> 
> нельзя ли как-нибудь обобщить brp-compress так, чтобы он сжимал не только
> документацию, но и файлы другого указанного типа в указанной packager'ом
> директории? И позволить вызывать его на стадии %install.

Это всегда можно прописать явно.
Хотя, интересно было бы иметь атрибут %compressed в секции %files.

-- 
Stay tuned,
  MhZ                                    mailto:mookid@sigent.ru
-----------
A fool and your money are soon partners.
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] strip

[aen]

Дмитрий, добрый вечер!
"Dmitry V. Levin" wrote:
> 

> 
> Цитирую сообщение полностью, в надежде, что Алексей прочтет его еще раз,
> после чего прочтет пункт 4 в вышеупомянутом README.ipl, а также
> дополнительную информацию, способ получения которой указан в последней
> строке этого пункта.
> 
> Если что-то в документации не достаточно ясно написано, спрашивайте.
> Но когда вопрос задается в форме, выдающей невнимательное чтение
> документации автором вопроса, становится очень обидно; для программиста
> сопровождение всегда дается сложнее, чем собственно программирование.

Несомненно, но Вы напрасно обижаетесь -- я читал все очень внимательно.

> 
> По поводу деталей policy: реализация в /usr/lib/rpm/brp-strip.
> 
> Вы предлагаете изменить значение макроса _strip_method с нынешнего
> значения по-умолчанию (executable) на новое, добавив туда что-то из списка
> relocatable, shared, static? Хорошо, но по каким причинам? Нехватка места
> на CD? И что именно добавлять будем?

Именно так. Надо добавить shared и static _по_ _умолчанию_.

> 
> В конечном итоге, незачем менять умолчание в /usr/lib/rpm/macros;
> достаточно изменить свои собственные настройки!

Это некоректно, если речь не идет о полях %packager, %vendor etc. Пакеты
должны быть со,ираемы одинаково у разных packgers, а потому изменение
_таких_ настроек должно быть явно прописано в spec. В то же время,
strip_shared и strip_static применяются настолько часто, что скорее надо
деклариовать их отсутствие. Именно об этом я и говорил. Но приводить
свое письмо еще раз не буду, так как Вы можете перечитать его в mailbox
или в архиве :-) 


Rgrds, Алексей.
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] strip

[Dmitry V. Levin]

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

On Thu, Dec 14, 2000 at 01:10:06AM +0300, aen wrote:
> Несомненно, но Вы напрасно обижаетесь -- я читал все очень внимательно.

Тогда зачем спрашивать, "как называется опция -T?" (tm)

> > Вы предлагаете изменить значение макроса _strip_method с нынешнего
> > значения по-умолчанию (executable) на новое, добавив туда что-то из списка
> > relocatable, shared, static? Хорошо, но по каким причинам? Нехватка места
> > на CD? И что именно добавлять будем?
> 
> Именно так. Надо добавить shared и static _по_ _умолчанию_.

Дело в том, что это есть ни что иное как site policy; я, например, как
разработчик не могу себе этого позволить, хотя сборку дистрибутива так
можно сделать. Только бы не отстрипать лишнего...

> > В конечном итоге, незачем менять умолчание в /usr/lib/rpm/macros;
> > достаточно изменить свои собственные настройки!
> 
> Это некоректно, если речь не идет о полях %packager, %vendor etc. Пакеты
> должны быть со,ираемы одинаково у разных packgers, а потому изменение
> _таких_ настроек должно быть явно прописано в spec. В то же время,
> strip_shared и strip_static применяются настолько часто, что скорее надо
> деклариовать их отсутствие. Именно об этом я и говорил. Но приводить
> свое письмо еще раз не буду, так как Вы можете перечитать его в mailbox
> или в архиве :-) 

Мне кажется, что это site policy, каковой место в файле /etc/rpm/macros.
Попробуйте меня переубедить! :)


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@fandra.org
Software Engineer   PGP pubkey http://www.fandra.org/users/ldv/pgpkeys.html
IPLabs Linux Team   http://linux.iplabs.ru
Fandra Project      http://www.fandra.org
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who its friends are.

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

Re: [devel] strip

[aen]

"Dmitry V. Levin" wrote:
>
> 
> Мне кажется, что это site policy, каковой место в файле /etc/rpm/macros.
> Попробуйте меня переубедить! :)

А что скажут другие разработчики? Никто не сталкивался с заметно
выросшим размером библиотек?


Rgrds, Алексей.
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] strip

[Dmitry V. Levin]

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

On Thu, Dec 14, 2000 at 05:29:55AM +0300, aen wrote:
> > Мне кажется, что это site policy, каковой место в файле /etc/rpm/macros.
> > Попробуйте меня переубедить! :)
> 
> А что скажут другие разработчики? Никто не сталкивался с заметно
> выросшим размером библиотек?

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

А на photo я уже записал в /etc/rpm/macros:
%_strip_method	executable shared static

Интересно, кроме XFree4, какие еще пакеты нужно принудительно отучать
strip'ать библиотеки?


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@fandra.org
Software Engineer   PGP pubkey http://www.fandra.org/users/ldv/pgpkeys.html
IPLabs Linux Team   http://linux.iplabs.ru
Fandra Project      http://www.fandra.org
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who its friends are.

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

Re: [devel] strip

[aen]

"Dmitry V. Levin" wrote:
> 
> On Thu, Dec 14, 2000 at 05:29:55AM +0300, aen wrote:
> > > Мне кажется, что это site policy, каковой место в файле /etc/rpm/macros.
> > > Попробуйте меня переубедить! :)
> >
> > А что скажут другие разработчики? Никто не сталкивался с заметно
> > выросшим размером библиотек?
> 
> Я же и сталкивался. Что поделать, такова участь разработчика, каковым я по
> умолчанию считаю всякого, кто собирает пакеты.
> 
> А на photo я уже записал в /etc/rpm/macros:
> %_strip_method  executable shared static
> 
> Интересно, кроме XFree4, какие еще пакеты нужно принудительно отучать
> strip'ать библиотеки?
> 
Не знаю. Но вообще-то надо посмотреть, чем brp-strip из старого rpm из
7.0 отличается от нашего из Appendix. С тем проблем не было.

Rgrds, AEN
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] strip

[Dmitry V. Levin]

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

On Thu, Dec 14, 2000 at 08:11:08AM +0300, aen wrote:
> > > > Мне кажется, что это site policy, каковой место в файле /etc/rpm/macros.
> > > > Попробуйте меня переубедить! :)
> > >
> > > А что скажут другие разработчики? Никто не сталкивался с заметно
> > > выросшим размером библиотек?
> > 
> > Я же и сталкивался. Что поделать, такова участь разработчика, каковым я по
> > умолчанию считаю всякого, кто собирает пакеты.
> > 
> > А на photo я уже записал в /etc/rpm/macros:
> > %_strip_method  executable shared static
> > 
> > Интересно, кроме XFree4, какие еще пакеты нужно принудительно отучать
> > strip'ать библиотеки?
> > 
> Не знаю. Но вообще-то надо посмотреть, чем brp-strip из старого rpm из
> 7.0 отличается от нашего из Appendix. С тем проблем не было.

В 7.0 strip еще делался вручную, spec-helper в MDK позднее появился. :)

По существу, что касается библиотек, то в обычных случаях стандартный
strip для библиотек таков:
$ strip -p -R .comment -R .note --strip-unneeded
("-R .note" иногда опускается, если в конкретном случае его использование
недопустимо, см. код /usr/lib/rpm/brp-strip).

Мой вопрос был о том, какие нестандартные случаи (a la XFree4) известны
разработчикам?


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@fandra.org
Software Engineer   PGP pubkey http://www.fandra.org/users/ldv/pgpkeys.html
IPLabs Linux Team   http://linux.iplabs.ru
Fandra Project      http://www.fandra.org
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who its friends are.

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

Re: [devel] strip

[Dmitry V. Levin]

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

On Thu, Dec 14, 2000 at 03:41:55AM +0300, Dmitry V. Levin wrote:
> > > Мне кажется, что это site policy, каковой место в файле /etc/rpm/macros.
> > > Попробуйте меня переубедить! :)
> > 
> > А что скажут другие разработчики? Никто не сталкивался с заметно
> > выросшим размером библиотек?
> 
> Я же и сталкивался. Что поделать, такова участь разработчика, каковым я по
> умолчанию считаю всякого, кто собирает пакеты.
> 
> А на photo я уже записал в /etc/rpm/macros:
> %_strip_method	executable shared static
> 
> Интересно, кроме XFree4, какие еще пакеты нужно принудительно отучать
> strip'ать библиотеки?

Проверено на практике (на photo), что никакие библиотеки из связки пакетов
glibc+gcc лучше не стрипать.


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@fandra.org
Software Engineer   PGP pubkey http://www.fandra.org/users/ldv/pgpkeys.html
IPLabs Linux Team   http://linux.iplabs.ru
Fandra Project      http://www.fandra.org
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who its friends are.

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