[devel] shared object not in path

[devel] shared object not in path

[Eugene Ostapets]

1. Есть seamonkey
2. Есть пожелание убрать *.so из /usr/lib
3. Есть find-requires, который видит библиотеку в /usr/lib на этапе 
упаковки пакета и прописывает на нее зависимость...

Варианты выхода из положения:
1. Забить на 1)
2. Забить на 2)
3. ?

-- 
WBR,
Eugene Ostapets

Re: [devel] shared object not in path

[Andrey Rahmatullin]

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

On Tue, Sep 27, 2005 at 06:38:27PM +0300, Eugene Ostapets wrote:
> 1. Есть seamonkey
Ни о чем не говорит.
> 2. Есть пожелание убрать *.so из /usr/lib
Чье пожелание? И в чем проблема?
> 3. Есть find-requires, который видит библиотеку в /usr/lib на этапе 
> упаковки пакета и прописывает на нее зависимость...
Не понял, откуда либа в /usr/lib, если (2)?


-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Если из-за включённого CONFIG_HARDEN_SHM что-то не работает, то это что-то
наверняка кривое.
		-- ldv in devel-kernel@

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

Re: [devel] shared object not in path

[Eugene Ostapets]

Andrey Rahmatullin пишет:

>On Tue, Sep 27, 2005 at 06:38:27PM +0300, Eugene Ostapets wrote:
>  
>
>>1. Есть seamonkey
>>    
>>
Бывшая mozilla-1.8beta

>Ни о чем не говорит.
>  
>
>>2. Есть пожелание убрать *.so из /usr/lib
>>    
>>
>Чье пожелание? И в чем проблема?
>  
>
Сборщиков других geckobased приложений...

>>3. Есть find-requires, который видит библиотеку в /usr/lib на этапе 
>>упаковки пакета и прописывает на нее зависимость...
>>    
>>
>Не понял, откуда либа в /usr/lib, если (2)?
>
>  
>
там линки, сами библиотеки в %mozilla_home...

-- 
WBR,
Eugene Ostapets

>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Devel mailing list
>Devel@altlinux.ru
>https://lists.altlinux.ru/mailman/listinfo/devel
>

Re: [devel] shared object not in path

[Alexey Gladkov]

Eugene Ostapets пишет:
> 1. Есть seamonkey
> 2. Есть пожелание убрать *.so из /usr/lib

Лучше убрать оттуда библиотеки. Их никто не использует. Но очень скоро
xulrunner будет с ними конфликтовать ...

Это "скоро" не за горами.
При обновлении firefox & co вероятно часть библиотек переползет в
/usr/lib. В этом случае mozilla станет конфликтовать с firefox.

> 3. Есть find-requires, который видит библиотеку в /usr/lib на этапе
> упаковки пакета и прописывает на нее зависимость...

В чем тут проблема ?

-- 
Rgrds, legion

[devel] Re: shared object not in path

[Alexey Tourbin]

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

On Tue, Sep 27, 2005 at 06:38:27PM +0300, Eugene Ostapets wrote:
> 1. Есть seamonkey
> 2. Есть пожелание убрать *.so из /usr/lib
> 3. Есть find-requires, который видит библиотеку в /usr/lib на этапе 
> упаковки пакета и прописывает на нее зависимость...

Чего в конечном счете вы хотите добиться?
Попробуйте %add_findprov_lib_path

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

Re: [devel] Re: shared object not in path

[Eugene Ostapets]

Alexey Tourbin пишет:

>On Tue, Sep 27, 2005 at 06:38:27PM +0300, Eugene Ostapets wrote:
>  
>
>>1. Есть seamonkey
>>2. Есть пожелание убрать *.so из /usr/lib
>>3. Есть find-requires, который видит библиотеку в /usr/lib на этапе 
>>упаковки пакета и прописывает на нее зависимость...
>>    
>>
>
>Чего в конечном счете вы хотите добиться?
>  
>
Чтобы в requires не попадали библиотеки, находящиеся в пакете...

>Попробуйте %add_findprov_lib_path
>  
>
Похоже это то слово, которое я искал...

-- 
WBR,
Eugene Ostapets

Re: [devel] Re: shared object not in path

[Anton D. Kachalov]

On Tue, Sep 27, 2005 at 09:59:41PM +0300, Eugene Ostapets wrote:
> Похоже это то слово, которое я искал...
А вы посмотрите в /usr/lib/rpm/*alt-linux/macros -- там много таких же полезных
слов.

--
mouse

Re: [devel] Re: shared object not in path

[Eugene Ostapets]

Anton D. Kachalov пишет:

>On Tue, Sep 27, 2005 at 09:59:41PM +0300, Eugene Ostapets wrote:
>  
>
>>Похоже это то слово, которое я искал...
>>    
>>
>А вы посмотрите в /usr/lib/rpm/*alt-linux/macros -- там много таких же полезных
>слов.
>  
>
Там их слишком много, а с учетом подчеркиваний и сокращений поиском 
ничего особо не добьешься...
Нужно будет где-нибудь на вики их все выложить и понемногу их описать...

-- 
WBR,
Eugene Ostapets

[devel] Re: shared object not in path

[Michael Shigorin]

On Tue, Sep 27, 2005 at 10:09:29PM +0300, Eugene Ostapets wrote:
> Нужно будет где-нибудь на вики их все выложить и понемногу их описать...

Отчасти здесь: http://docs.altlinux.ru/alt/devel/ch01s02.html#id2813079

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/
 ----       visit our conference (Oct 1):
--          http://conference.osdn.org.ua

[devel] Re: shared object not in path

[Alexey Tourbin]

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

On Tue, Sep 27, 2005 at 09:59:41PM +0300, Eugene Ostapets wrote:
> >Чего в конечном счете вы хотите добиться?
> Чтобы в requires не попадали библиотеки, находящиеся в пакете...

В requires или в provides?
Подумайте. :)

В requires они не могут не попадать, но могут оптимизироваться из
requires, если они есть одновременно в requires и в provides.

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

Re: [devel] Re: shared object not in path

[Eugene Ostapets]

Alexey Tourbin пишет:

>On Tue, Sep 27, 2005 at 09:59:41PM +0300, Eugene Ostapets wrote:
>  
>
>>>Чего в конечном счете вы хотите добиться?
>>>      
>>>
>>Чтобы в requires не попадали библиотеки, находящиеся в пакете...
>>    
>>
>
>В requires или в provides?
>Подумайте. :)
>
>В requires они не могут не попадать, но могут оптимизироваться из
>requires, если они есть одновременно в requires и в provides.
>  
>
Не нужно меня пытаться запутать... Я и сам могу запутаться...:)
Мне нужно чтобы библиотека, находящаяся в пакете не попадала в requires 
этого самого пакета... Т.е. чтобы пакет, полностью работоспособный и 
самодостаточный, не обламывался при установке на требовании библиотеки в 
нем же находящейся...

-- 
WBR,
Eugene Ostapets

[devel] Re: shared object not in path

[Alexey Tourbin]

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

On Tue, Sep 27, 2005 at 10:13:21PM +0300, Eugene Ostapets wrote:
> Не нужно меня пытаться запутать... Я и сам могу запутаться...:)
> Мне нужно чтобы библиотека, находящаяся в пакете не попадала в requires 
> этого самого пакета... Т.е. чтобы пакет, полностью работоспособный и 
> самодостаточный, не обламывался при установке на требовании библиотеки в 
> нем же находящейся...

Он и не обломится.  Если пакет одновременно требует и предоставляет одну
и ту же зависимость, то это не считается конфликтом.  Но ALT rpm такие
самоудовлетворённые зависимости оптимизирует и оставляет только provides.

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

Re: [devel] Re: shared object not in path

[Eugene Ostapets]

Alexey Tourbin пишет:

>On Tue, Sep 27, 2005 at 10:13:21PM +0300, Eugene Ostapets wrote:
>  
>
>>Не нужно меня пытаться запутать... Я и сам могу запутаться...:)
>>Мне нужно чтобы библиотека, находящаяся в пакете не попадала в requires 
>>этого самого пакета... Т.е. чтобы пакет, полностью работоспособный и 
>>самодостаточный, не обламывался при установке на требовании библиотеки в 
>>нем же находящейся...
>>    
>>
>
>Он и не обломится.  Если пакет одновременно требует и предоставляет одну
>и ту же зависимость, то это не считается конфликтом.  Но ALT rpm такие
>самоудовлетворённые зависимости оптимизирует и оставляет только provides.
>  
>
В том-то и беда, что пока не добавил %add_findprov_lib_path 
%mozilla_home пакет требовал библиотеку находящуюся в нем по пути 
%mozilla_home, но rpm не находил ее в самом пакете...

-- 
WBR,
Eugene Ostapets

Re: [devel] Re: shared object not in path

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

On Wed, Sep 28, 2005 at 12:24:57AM +0400, Алексей Турбин wrote:

AT> Он и не обломится.  Если пакет одновременно требует и предоставляет одну
AT> и ту же зависимость, то это не считается конфликтом.  Но ALT rpm такие
AT> самоудовлетворённые зависимости оптимизирует и оставляет только provides.

Представь себе ситуацию:
1. у нас есть некий модуль перла, который написан исключительно для
использования в какой-то программе, и поэтому его нельзя устанавливать
глобально, посему он просто лежит файликом в /usr/share/%name.

2. некий скрипт, который живёт, скажем, в /usr/bin, лежит в этом пакете и
имеет use lib '/usr/share/%name' хочет этот модуль.

Результат -- либо надо делать provides на этот модуль (что принципиально
неправильно, потому как этот модуль _не_ предоставляется, и использоваться
другими программами не должен/не может), либо мы получим неустанавливаемый
пакет.

И это большая проблема, которая решается, видимо, только:
а) наличием механизма, который убирает requires на всё, что мы provides
б) "виртуальных" provides, которые используются только в этом механизме
автоматизации, и не оказываются в последствии в заголовках rpm.

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

http://freesource.info
----------------------------------------------------------------------------
LATER наступило.  Патчи в аттачах.
		-- raorn in #5429

Re: [devel] Re: shared object not in path

[Aleksey Avdeev]

Денис Смирнов пишет:
> On Wed, Sep 28, 2005 at 12:24:57AM +0400, Алексей Турбин wrote:
> 
> AT> Он и не обломится.  Если пакет одновременно требует и предоставляет одну
> AT> и ту же зависимость, то это не считается конфликтом.  Но ALT rpm такие
> AT> самоудовлетворённые зависимости оптимизирует и оставляет только provides.
> 
> Представь себе ситуацию:
> 1. у нас есть некий модуль перла, который написан исключительно для
> использования в какой-то программе, и поэтому его нельзя устанавливать
> глобально, посему он просто лежит файликом в /usr/share/%name.
> 
> 2. некий скрипт, который живёт, скажем, в /usr/bin, лежит в этом пакете и
> имеет use lib '/usr/share/%name' хочет этот модуль.

   Именно такую ситуацию я имею с bugzilla`ми: куча перлового кода, 
специфичного только для данного приложения, который не находятся 
(неудовлетворенные зависимости) если его не включать в пути поиска, 
п начинает провайдеца -- если туда включить. Приходится писать 
зависимости руками... :-(

> И это большая проблема, которая решается, видимо, только:
> а) наличием механизма, который убирает requires на всё, что мы provides
> б) "виртуальных" provides, которые используются только в этом механизме
> автоматизации, и не оказываются в последствии в заголовках rpm.

   в) механизм фильтрации _финального_ списка provides.

-- 

С уважением. Алексей.

Re: [devel] shared object not in path

[Andrei Bulava]

Aleksey Avdeev wrote:
>   в) механизм фильтрации _финального_ списка provides.

Каковой можно сделать местечковым хаком в конкретном spec-файле, а можно
и "омакрить" (в архивах devel уже было обсуждение).

-- 
// AB1002-UANIC

Re: [devel] shared object not in path

[Aleksey Avdeev]

Andrei Bulava пишет:
> Aleksey Avdeev wrote:
> 
>>  в) механизм фильтрации _финального_ списка provides.
> 
> 
> Каковой можно сделать местечковым хаком в конкретном spec-файле, а можно
> и "омакрить" (в архивах devel уже было обсуждение).
> 

   Кажется я это пропустил... :-(

   Спасибо за наводку: нашёл 
<http://lists.altlinux.ru/pipermail/devel/2004-May/011087.html> и 
<http://lists.altlinux.ru/pipermail/python-devel/2005-June/000112.html>. 
  Это всё (в смысле идей), или ещё варианты есть?

-- 

С уважением. Алексей.

[devel] Re: shared object not in path

[Aleksey Avdeev]

Michael Shigorin пишет:
> On Thu, Sep 29, 2005 at 04:45:37PM +0400, Aleksey Avdeev wrote:
> 
>>>>в) механизм фильтрации _финального_ списка provides.
>>>
>>>Каковой можно сделать местечковым хаком в конкретном spec-файле, а можно
>>>и "омакрить" (в архивах devel уже было обсуждение).
>>
>>Кажется я это пропустил... :-(
>>
>>Спасибо за наводку: нашёл 
>><http://lists.altlinux.ru/pipermail/devel/2004-May/011087.html> и 
>><http://lists.altlinux.ru/pipermail/python-devel/2005-June/000112.html>. 
>>Это всё (в смысле идей), или ещё варианты есть?
> 
> 
> Закинете на wiki.sisyphus.ru/devel/spectips?
> 

<http://wiki.sisyphus.ru/devel/SpecTips/FiltrProvides>

PS: Если кто дополнит/отредактирует -- буду только ЗА. :-)

-- 

С уважением. Алексей.