[Comm] Зависимости в пакетах.

[Comm] Зависимости в пакетах.

[spider]

Скачал OO-2.0 от infra. Это тарболл в котором лежит куча rpm. Многие из 
них требуют друг друга взаимно. Например core01 требует core02, та, в 
свою очередь требует core01. Замкнутый круг.

Аналогичная ситуация имеет место и для пакета netpbm, который в AM2.4 
состоит из трех частей, каждая из которых требует наличия остальных. При 
попытке обновить netpbm из backports получаем отказ из-за 
несовместимости того, что стоит и того, что прикладывается.

Вопрос 1: Как правильно с этим бороться? Какие опции надо указать rpm, 
что бы поставить все наиболее чисто?

Вопрос 2: Почему многие изначально цельные пакеты попадают в AM в сильно 
расчлененном виде? Например, djvulibre -- единый пакет, почему бы его и 
не оставить в таком виде? За исключением приблуды для web все части 
пользователю необходимы одновременно, и lib и viewer, и утилиты и плагин.

Re: [Comm] Зависимости в пакетах.

[Genix]

spider wrote:

> Вопрос 1: Как правильно с этим бороться? Какие опции надо указать rpm, 
> что бы поставить все наиболее чисто?

1) rpm -Uvh rpm1 rpm2 rpm3
2) сделать для них genbasedir и воспользоваться apt'ом

-- 
У каждого в башке свои тараканы...

Re: [Comm] Зависимости в пакетах.

[Alexander Volkov]

On Thu, 17 Nov 2005 16:38:41 +0300, spider wrote:

> Вопрос 1: Как правильно с этим бороться? Какие опции надо указать rpm,  
> что бы поставить все наиболее чисто?

у меня поставилось без проблем так:
sudo apt-get install open*rpm
в каталоге с ними

-- 
Regards, Alexander.

Re: [Comm] Зависимости в пакетах.

[spider]

Alexander Volkov пишет:
> On Thu, 17 Nov 2005 16:38:41 +0300, spider wrote:
> 
>> Вопрос 1: Как правильно с этим бороться? Какие опции надо указать 
>> rpm,  что бы поставить все наиболее чисто?
> 
> 
> у меня поставилось без проблем так:
> sudo apt-get install open*rpm
> в каталоге с ними
> 
Спасибо, счас попробую.

[Comm] Зависимости в пакетах.

[Gleb Stiblo]

On Thu, Nov 17, 2005 at 04:38:41PM +0300, spider wrote:
[...]
s> Вопрос 1: Как правильно с этим бороться? Какие опции надо указать rpm, 
s> что бы поставить все наиболее чисто?
ставить их в одной транзакции, к примеру rpm -Uvh пакет1.rpm пакет2.rpm

s> Вопрос 2: Почему многие изначально цельные пакеты попадают в AM в сильно 
s> расчлененном виде? Например, djvulibre -- единый пакет, почему бы его и 
s> не оставить в таком виде? За исключением приблуды для web все части 
s> пользователю необходимы одновременно, и lib и viewer, и утилиты и плагин.
не всегда, к примеру, довольно часто происходит так, что нужна лишь
библиотека, а 'viewer, и утилиты и плагин' не требуются.

-- 
Gleb Stiblo AKA UlfR 	<g.stiblo@sam-solutions.net>

Re: [Comm] Зависимости в пакетах.

[spider]

Gleb Stiblo пишет:
> > ...Почему многие изначально цельные пакеты попадают в AM в сильно 
> > расчлененном виде? Например, djvulibre -- единый пакет, почему бы его и 
> > не оставить в таком виде? За исключением приблуды для web все части 
> > пользователю необходимы одновременно, и lib и viewer, и утилиты и плагин.
> не всегда, к примеру, довольно часто происходит так, что нужна лишь
> библиотека, а 'viewer, и утилиты и плагин' не требуются.

Не верю про библиотеку DjVu без вьюера и плагина для рядового 
пользователя, тем более, разработчика. Одна лишь библиотека djvu 
абсолютно бесполезна, если к ней нет ничего, что бы ее использовало.

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

[Comm] Зависимости в пакетах.

[Gleb Stiblo]

On Mon, Nov 28, 2005 at 09:03:36PM +0300, spider wrote:
s>>> ...Почему многие изначально цельные пакеты попадают в AM в сильно 
s>>> расчлененном виде? Например, djvulibre -- единый пакет, почему бы его и 
s>>> не оставить в таком виде? За исключением приблуды для web все части 
s>>> пользователю необходимы одновременно, и lib и viewer, и утилиты и плагин.
GS>>не всегда, к примеру, довольно часто происходит так, что нужна лишь
GS>>библиотека, а 'viewer, и утилиты и плагин' не требуются.
s> 
s> Не верю про библиотеку DjVu без вьюера и плагина для рядового 
s> пользователя, тем более, разработчика. Одна лишь библиотека djvu 
s> абсолютно бесполезна, если к ней нет ничего, что бы ее использовало.
да, но на оборот-то неверно.
попытаюсь объяснить более подробнее:

djvu-common - DjVu shared files
djvu-devel - devel headers for libdjvu
djvu-doc - docs about djvu technology
djvu-utils - DjVu utilites
djvu-viewer - standalone DjVu viewer

^ это как минимум один из просмоторщиков, но ведь есть (могут быть) и
другие более подходящие для пользователей; этот вьювер использует qt, а
к примеру у пользователя gnome qt отстствует -- он себе имеет
возможность поставить просмоторщик написанный на gtk; а были бы
djvu-viewer и libdjvu в одном пакете, тогда бедный пользователь gnome
получит к своему вьюверу, ещё один не используемый и qt в придачу.

Т.е. библиотека сама по себе никому не нужна, но так как приложений её
использующих может быть много и не все они могут быть необходимы
пользователю, то хорошо, когда есть возможность устанавливать выборочно.


djvu-xmltools - DjVu XML tools
kdebase-kio - Internet protocol plugins for KDE
libdjvu - DjVu encoder libraries
mozilla-plugin-djvu - DjVu NPAPI plugin




-- 
Gleb Stiblo AKA UlfR 	<g.stiblo@sam-solutions.net>