[devel] зависимости на модули перла идущие с пакетом

[devel] зависимости на модули перла идущие с пакетом

[Денис Смирнов]

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

Вводная: есть пакет, в нём есть некий модуль perl'а, использующийся
исключительно для внутренних целей, посему лежащий в %_libdir/%name.
При создании пакета автоматически создаётся зависимость на этот модуль
(так как он используется скриптами, лежащими в пакете), но при этом с
модуль в provides не добавляется.

Задача: любо чтобы этот модуль не добавлялся и в reqires тоже (идеальный
вариант, так как модуль внутренний только для себя), либо чтобы он был и в
Provides.

Как решать?

-- 
С уважением, Денис

http://freesource.info


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

Re: [devel] зависимости на модули перла идущие с пакетом

[Dmitry V. Levin]

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

On Thu, Jan 08, 2004 at 01:03:29AM +0300, Денис Смирнов wrote:
> Вводная: есть пакет, в нём есть некий модуль perl'а, использующийся
> исключительно для внутренних целей, посему лежащий в %_libdir/%name.
> При создании пакета автоматически создаётся зависимость на этот модуль
> (так как он используется скриптами, лежащими в пакете), но при этом с
> модуль в provides не добавляется.
> 
> Задача: любо чтобы этот модуль не добавлялся и в reqires тоже (идеальный
> вариант, так как модуль внутренний только для себя), либо чтобы он был и в
> Provides.
> 
> Как решать?

Добавить легко:
согласно /usr/share/doc/rpm-4.0.4/README.ALT-ru_RU.KOI8-R,
достаточно поместить в spec-файл строку
%add_findprov_lib_path %_libdir/%name

Убрать сложнее:
Надо переопределить %__find_requires на свой скрипт, который отфильтрует
результат работы системного %__find_requires.  Если вы придумаете более
элегантный метод, напишите.


-- 
ldv

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

[devel] Re: зависимости на модули перла идущие с пакетом

[Michael Shigorin]

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

On Thu, Jan 08, 2004 at 03:00:34AM +0300, Dmitry V. Levin wrote:
> Добавить легко: %add_findprov_lib_path %_libdir/%name
> Убрать сложнее: Надо переопределить %__find_requires на свой
> скрипт, который отфильтрует результат работы системного
> %__find_requires.  Если вы придумаете более элегантный метод,
> напишите.

%del_findprov_lib_path %_libdir/%name
?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[devel] Re: зависимости на модули перла идущие с пакетом

[Alexey Tourbin]

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

On Thu, Jan 08, 2004 at 01:03:29AM +0300, Денис Смирнов wrote:
> Вводная: есть пакет, в нём есть некий модуль perl'а, использующийся
> исключительно для внутренних целей, посему лежащий в %_libdir/%name.

%define _perl_lib_path %_libdir/%name

> При создании пакета автоматически создаётся зависимость на этот модуль
> (так как он используется скриптами, лежащими в пакете), но при этом с
> модуль в provides не добавляется.

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

Re: [devel] Re: зависимости на модули перла идущие с пакетом

[Dmitry V. Levin]

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

On Thu, Jan 08, 2004 at 09:44:15AM +0200, Michael Shigorin wrote:
> On Thu, Jan 08, 2004 at 03:00:34AM +0300, Dmitry V. Levin wrote:
> > Добавить легко: %add_findprov_lib_path %_libdir/%name
> > Убрать сложнее: Надо переопределить %__find_requires на свой
> > скрипт, который отфильтрует результат работы системного
> > %__find_requires.  Если вы придумаете более элегантный метод,
> > напишите.
> 
> %del_findprov_lib_path %_libdir/%name
> ?

Нет, речь идет не об удалении %_libdir/%name из списка поиска PROVIDES,
а об удалении REQUIRES на объекты в %_libdir/%name.

Какие ещё будут предложения?


-- 
ldv

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

[devel] Re: зависимости на модули перла идущие с пакетом

[Michael Shigorin]

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

On Sat, Jan 10, 2004 at 02:54:25AM +0300, Dmitry V. Levin wrote:
> > > Добавить легко: %add_findprov_lib_path %_libdir/%name
> > > Убрать сложнее: Надо переопределить %__find_requires на свой
> > > скрипт, который отфильтрует результат работы системного
> > > %__find_requires.  Если вы придумаете более элегантный метод,
> > > напишите.
> > %del_findprov_lib_path %_libdir/%name
> > ?
> Нет, речь идет не об удалении %_libdir/%name из списка поиска
> PROVIDES, а об удалении REQUIRES на объекты в %_libdir/%name.

Разумеется, это был недоправленный cut'n'paste.

%del_findreq_lib_path (который отфильтрует из вывода findreq один
или несколько префиксов) или на худой конец %del_findreq_regex ?

Хотя все равно хакообразно.  

Может, я тупой, но смысла выбирать именно такой баланс между
"любопытством" при поиске анонсируемых и требуемых ресурсов
(когда by default может запрашиваться больше, чем анонсируется)
-- не вижу:

* если сделано для улучшения SNR по зависимостям -- все равно
  приходится добавлять анонсы руками => противоречие с одним из
  первых тезисов ALT-Packaging;
* если так получилось, что findreq быстрее стал более любопытным
  -- может быть осмысленно в будущем стараться такие изменения
  поведения производить синхронно?

Т.е. если уж решили, что self requires -- это не бессмысленность
само по себе, то давайте как-то консистентно подходить к тому,
что первично -- предоставляемые или требуемые ресурсы.

Если бы "слишком любопытным" был findprov, был бы просто лишний
шум; а так добавляется бессмысленная потеря времени.

Или я неправ, а это временное нава^Wявление?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

Re: [devel] Re: зависимости на библиотеки идущие с пакетом

[Dmitry V. Levin]

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

On Sat, Jan 10, 2004 at 08:54:17AM +0200, Michael Shigorin wrote:
> On Sat, Jan 10, 2004 at 02:54:25AM +0300, Dmitry V. Levin wrote:
> > > > Добавить легко: %add_findprov_lib_path %_libdir/%name
> > > > Убрать сложнее: Надо переопределить %__find_requires на свой
> > > > скрипт, который отфильтрует результат работы системного
> > > > %__find_requires.  Если вы придумаете более элегантный метод,
> > > > напишите.
> > > %del_findprov_lib_path %_libdir/%name
> > > ?
> > Нет, речь идет не об удалении %_libdir/%name из списка поиска
> > PROVIDES, а об удалении REQUIRES на объекты в %_libdir/%name.
> 
> Разумеется, это был недоправленный cut'n'paste.
> 
> %del_findreq_lib_path (который отфильтрует из вывода findreq один
> или несколько префиксов) или на худой конец %del_findreq_regex ?
> 
> Хотя все равно хакообразно.  
> 
> Может, я тупой, но смысла выбирать именно такой баланс между
> "любопытством" при поиске анонсируемых и требуемых ресурсов
> (когда by default может запрашиваться больше, чем анонсируется)
> -- не вижу:

А зря.  Напомню, откуда все эти find{req,prov}_lib_path родом.

Когда-то был релиз ALM2.2 (может, ещё помните), и был там пакет с
OpenOffice.org.  В пакете том, помимо всего прочего, было два файла,
/usr/lib/openoffice/program/libgcc_s.so.1 и
/usr/lib/openoffice/program/libstdc++.so.5
И предоставлял сей пакет, среди всего прочего, libgcc_s.so.1 и
libstdc++.so.5.  И представьте себе, во время dist-upgrade поставился
у пользователей этот замечательный пакет вместо libgcc3.2 и libstdc++3.2
И спрашивали потом эти счастливые обладатели свежеобновлённой системы,
почему у них apt-get не запускается, и ещё много полезных программ не
запускается.  И говорили им потом, что нельзя было устанавливать пакет
openoffice-1.0.2-alt2, но было уже поздно.

Вот эта история навела на мысль, что искать provides нужно по умолчанию
только там, где по умолчанию ищет /lib/ld-linux.so.2


-- 
ldv

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

[devel] Re: зависимости на библиотеки идущие с пакетом

[Michael Shigorin]

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

On Sat, Jan 10, 2004 at 03:48:29PM +0300, Dmitry V. Levin wrote:
> > Может, я тупой, но смысла выбирать именно такой баланс между
                                                    ^^^^^^
> > "любопытством" при поиске анонсируемых и требуемых ресурсов
> > (когда by default может запрашиваться больше, чем анонсируется)
> > -- не вижу:
> А зря.  Напомню, откуда все эти find{req,prov}_lib_path родом.

Это как раз понятно.

> Когда-то был релиз ALM2.2 (может, ещё помните), и был там пакет с
> OpenOffice.org.  И предоставлял сей пакет, среди всего прочего,
> libgcc_s.so.1 и libstdc++.so.5.  Вот эта история навела на
> мысль, что искать provides нужно по умолчанию только там, где
> по умолчанию ищет /lib/ld-linux.so.2

Все это было бы хорошо, если бы поиск requires был скорректирован
таким же образом.  По крайней мере опционально.

Рассматривая apache.spec:

%package mod_perl
[...]
# ugly hack :-/
Provides: perl(mod_perl.pm)

потому как

~> rpm -qRp /var/ftp/pub/Linux/ALT/Sisyphus/i586/RPMS.master/apache-mod_perl-1.3.29rusPL30.18-alt2.i586.rpm | grep mod_perl
perl(mod_perl.pm) >= 0:1.01
perl(mod_perl.pm) >= 0:1.1701
perl(mod_perl_hooks.pm)  

Зачем вообще self requires?  Минусы -- вот они, а плюсы-то какие?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

Re: [devel] Re: зависимости идущие с пакетом

[Dmitry V. Levin]

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

On Sat, Jan 10, 2004 at 04:43:28PM +0200, Michael Shigorin wrote:
> On Sat, Jan 10, 2004 at 03:48:29PM +0300, Dmitry V. Levin wrote:
> > > Может, я тупой, но смысла выбирать именно такой баланс между
>                                                     ^^^^^^
> > > "любопытством" при поиске анонсируемых и требуемых ресурсов
> > > (когда by default может запрашиваться больше, чем анонсируется)
> > > -- не вижу:
> > А зря.  Напомню, откуда все эти find{req,prov}_lib_path родом.
> 
> Это как раз понятно.
> 
> > Когда-то был релиз ALM2.2 (может, ещё помните), и был там пакет с
> > OpenOffice.org.  И предоставлял сей пакет, среди всего прочего,
> > libgcc_s.so.1 и libstdc++.so.5.  Вот эта история навела на
> > мысль, что искать provides нужно по умолчанию только там, где
> > по умолчанию ищет /lib/ld-linux.so.2
> 
> Все это было бы хорошо, если бы поиск requires был скорректирован
> таким же образом.  По крайней мере опционально.

Всё же есть разница между библиотечными и перловыми зависимостями.

> Зачем вообще self requires?

self requires - это, видимо, такие зависимости, которые предоставляются
самим пакетом?  В таком случае наименее очевидно, как их распознавать.


-- 
ldv

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

[devel] Re: зависимости идущие с пакетом

[Michael Shigorin]

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

On Sat, Jan 10, 2004 at 06:41:39PM +0300, Dmitry V. Levin wrote:
> > Все это было бы хорошо, если бы поиск requires был
> > скорректирован таким же образом.  По крайней мере
> > опционально.
> Всё же есть разница между библиотечными и перловыми
> зависимостями.

Это был пример, попавшийся под руку -- с точно таким же
поведением (балансом).

> > Зачем вообще self requires?
> self requires - это, видимо, такие зависимости, которые
> предоставляются самим пакетом?

Угу.

> В таком случае наименее очевидно, как их распознавать.

Понимаю.  Было начал думать в сторону двух списков -- "внешние"
provides и "какие-там-еще" (объединение которых для заданного
пакета вычитается из его requires), но что-то сейчас торможу.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

Re: [devel] Re: зависимости идущие с пакетом

[Alexey Lubimov]

Dmitry V. Levin пишет:
> On Sat, Jan 10, 2004 at 04:43:28PM +0200, Michael Shigorin wrote:
> 
>>On Sat, Jan 10, 2004 at 03:48:29PM +0300, Dmitry V. Levin wrote:
>>
>>>>Может, я тупой, но смысла выбирать именно такой баланс между
>>
>>                                                    ^^^^^^
>>
>>>>"любопытством" при поиске анонсируемых и требуемых ресурсов
>>>>(когда by default может запрашиваться больше, чем анонсируется)
>>>>-- не вижу:
>>>
>>>А зря.  Напомню, откуда все эти find{req,prov}_lib_path родом.
>>
>>Это как раз понятно.
>>
>>
>>>Когда-то был релиз ALM2.2 (может, ещё помните), и был там пакет с
>>>OpenOffice.org.  И предоставлял сей пакет, среди всего прочего,
>>>libgcc_s.so.1 и libstdc++.so.5.  Вот эта история навела на
>>>мысль, что искать provides нужно по умолчанию только там, где
>>>по умолчанию ищет /lib/ld-linux.so.2
>>
>>Все это было бы хорошо, если бы поиск requires был скорректирован
>>таким же образом.  По крайней мере опционально.
> 
> 
> Всё же есть разница между библиотечными и перловыми зависимостями.
> 
> 
>>Зачем вообще self requires?
> 
> 
> self requires - это, видимо, такие зависимости, которые предоставляются
> самим пакетом?  В таком случае наименее очевидно, как их распознавать.

зависимость на файл, который есть в %files спека?

Re: [devel] self requires

[Dmitry V. Levin]

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

On Sat, Jan 10, 2004 at 07:04:11PM +0200, Michael Shigorin wrote:
> On Sat, Jan 10, 2004 at 06:41:39PM +0300, Dmitry V. Levin wrote:
> > > Зачем вообще self requires?
> > self requires - это, видимо, такие зависимости, которые
> > предоставляются самим пакетом?
> 
> Угу.
> 
> > В таком случае наименее очевидно, как их распознавать.
> 
> Понимаю.  Было начал думать в сторону двух списков -- "внешние"
> provides и "какие-там-ещё" (объединение которых для заданного
> пакета вычитается из его requires), но что-то сейчас торможу.

Да, тема интересная сама по себе.

Помню, Алексей Турбин предлагал исключать из списка requires то, что было
найдено и помещено в список provides.  Было бы неплохо сделать, но это
не решит задачу в случае, когда зависимости настолько внутренние для
пакета, что не попадают в provides - именно о таких шла речь в обоих
примерах.

У меня есть несколько идей, реализация которых могла бы снять часть
этих проблем:
1. Для ELFов, содержащих RPATH, имеет смысл не включать зависимости на
библиотеки, находящиеся в RPATH, при условии, что эти библиотеки находятся
в том же пакете.
2. Для перловых скриптов имеет смысл не включать зависимости на модули,
при условии, что эти модули находятся в том же пакете.


-- 
ldv

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

[devel] Re: self requires

[Michael Shigorin]

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

On Sat, Jan 10, 2004 at 09:20:23PM +0300, Dmitry V. Levin wrote:
> > Понимаю.  Было начал думать в сторону двух списков -- "внешние"
> > provides и "какие-там-ещё" (объединение которых для заданного
> > пакета вычитается из его requires), но что-то сейчас торможу.
> Да, тема интересная сама по себе.
> Помню, Алексей Турбин предлагал исключать из списка requires
> то, что было найдено и помещено в список provides.

Ну для начала.  На самом деле упрощение списка тоже хорошо, но
уже является приятным дополнением скорее.

> Было бы неплохо сделать, но это не решит задачу в случае, когда
> зависимости настолько внутренние для пакета, что не попадают в
> provides - именно о таких шла речь в обоих примерах.

Ммм... даже если полностью не решит, может упростить.

> У меня есть несколько идей, реализация которых могла бы снять
> часть этих проблем:
> 1. Для ELFов, содержащих RPATH, имеет смысл не включать
> зависимости на библиотеки, находящиеся в RPATH, при условии,
> что эти библиотеки находятся в том же пакете.

Для меня RPATH/TEXTREL -- просто ключевые слова со смутно
понятным смыслом (в смысле куда копать -- понятно, но
неинтересно) :-)

> 2. Для перловых скриптов имеет смысл не включать зависимости на
> модули, при условии, что эти модули находятся в том же пакете.

Да, тут может быть и проще.  Может, с них и начать?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

Re: [devel] Re: self requires

[Dmitry V. Levin]

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

On Sat, Jan 10, 2004 at 08:44:22PM +0200, Michael Shigorin wrote:
> On Sat, Jan 10, 2004 at 09:20:23PM +0300, Dmitry V. Levin wrote:
> > > Понимаю.  Было начал думать в сторону двух списков -- "внешние"
> > > provides и "какие-там-ещё" (объединение которых для заданного
> > > пакета вычитается из его requires), но что-то сейчас торможу.
> > Да, тема интересная сама по себе.
> > Помню, Алексей Турбин предлагал исключать из списка requires
> > то, что было найдено и помещено в список provides.
> 
> Ну для начала.  На самом деле упрощение списка тоже хорошо, но
> уже является приятным дополнением скорее.

Полезным - чем меньше лишних зависимостей, тем быстрее работают
librpm и apt-get.

> > Было бы неплохо сделать, но это не решит задачу в случае, когда
> > зависимости настолько внутренние для пакета, что не попадают в
> > provides - именно о таких шла речь в обоих примерах.
> 
> Ммм... даже если полностью не решит, может упростить.
> 
> > У меня есть несколько идей, реализация которых могла бы снять
> > часть этих проблем:
> > 1. Для ELFов, содержащих RPATH, имеет смысл не включать
> > зависимости на библиотеки, находящиеся в RPATH, при условии,
> > что эти библиотеки находятся в том же пакете.
> 
> Для меня RPATH/TEXTREL -- просто ключевые слова со смутно
> понятным смыслом (в смысле куда копать -- понятно, но
> неинтересно) :-)

А я так старался сформулировать поточнее. :)

> > 2. Для перловых скриптов имеет смысл не включать зависимости на
> > модули, при условии, что эти модули находятся в том же пакете.
> 
> Да, тут может быть и проще.  Может, с них и начать?

Нет, это дело технически не очень простое, так что я пока подожду,
когда все заинтересованные выскажутся.


-- 
ldv

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