From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <legion@altlinux.ru>
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
	version=3.2.5
Message-ID: <51027EBC.4000708@altlinux.ru>
Date: Fri, 25 Jan 2013 16:46:52 +0400
From: Alexey Gladkov <legion@altlinux.ru>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130117 Thunderbird/17.0.2
MIME-Version: 1.0
To: devel@lists.altlinux.org
References: <20130125092845.GA16892@dad.imath.kiev.ua>
	<20130125105354.GB19811@altlinux.org> <510276E3.90407@altlinux.ru>
	<20130125123248.GD22369@altlinux.org>
In-Reply-To: <20130125123248.GD22369@altlinux.org>
X-Enigmail-Version: 1.5a1pre
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [devel] non-strict deps
X-BeenThere: devel@lists.altlinux.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ALT Linux Team development discussions <devel@lists.altlinux.org>
List-Id: ALT Linux Team development discussions <devel.lists.altlinux.org>
List-Unsubscribe: <https://lists.altlinux.org/mailman/options/devel>,
	<mailto:devel-request@lists.altlinux.org?subject=unsubscribe>
List-Archive: <http://lists.altlinux.org/pipermail/devel>
List-Post: <mailto:devel@lists.altlinux.org>
List-Help: <mailto:devel-request@lists.altlinux.org?subject=help>
List-Subscribe: <https://lists.altlinux.org/mailman/listinfo/devel>,
	<mailto:devel-request@lists.altlinux.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jan 2013 12:47:09 -0000
Archived-At: <http://lore.altlinux.org/devel/51027EBC.4000708@altlinux.ru/>
List-Archive: <http://lore.altlinux.org/devel/>
List-Post: <mailto:devel@altlinux.org>

25.01.2013 16:32, Dmitry V. Levin wrote:
> On Fri, Jan 25, 2013 at 04:13:23PM +0400, Alexey Gladkov wrote:
>> 25.01.2013 14:53, Dmitry V. Levin wrote:
>>> Проанализировав множество нестрогих внутрипакетных зависимостей, которые
>>> диагностирует rpm-build, я пришел к выводу, что среди них выделяется
>>> только один класс зависимостей, которые нужно сохранить,
>>> а все остальные следует сделать строгими.
>>
>> Можно ли рассказать подробнее т.к. меня это касается?
> 
> Тестируется следующий алгоритм: подпакет A исходного пакета S
> автоматически получает строгую зависимость на подпакет B исходного
> пакета S, если у подпакета A есть такая зависимость X, что подпакет B
> является единственным подпакетом исходного пакета S, удовлетворяющим
> эту зависимость X.

Т.е. если подпакет A имеет зависимость на некий функционал, который
может быть предоставлен другим пакетом и который предоставляет
подпакет B (эталонная реализация), то A получит жёсткую зависимость на
B ???

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

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

-- 
Rgrds, legion