From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mike@fly.osdn.org.ua>
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.2.5
Date: Tue, 13 Oct 2009 10:31:12 +0300
From: Michael Shigorin <mike@osdn.org.ua>
To: ALT Linux Team development discussions <devel@lists.altlinux.org>
Message-ID: <20091013073112.GI26079@osdn.org.ua>
Mail-Followup-To: ALT Linux Team development discussions
	<devel@lists.altlinux.org>
References: <8d778a620910090903s786e700fwb532c061725c4a9b@mail.gmail.com>
	<679044850910100329w27cb7323ide3abc3fc0441704@mail.gmail.com>
	<4AD29685.906@mmedia2.kemsu.ru>
	<20091012151340.GI26079@osdn.org.ua>
	<4AD3ECF1.3000202@mmedia2.kemsu.ru>
	<20091013071015.GE26079@osdn.org.ua>
	<4AD42EE4.5090800@mmedia2.kemsu.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4AD42EE4.5090800@mmedia2.kemsu.ru>
User-Agent: Mutt/1.4.2.1i
Subject: Re: [devel] [spec-lynch] trilinos
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: Tue, 13 Oct 2009 07:31:17 -0000
Archived-At: <http://lore.altlinux.org/devel/20091013073112.GI26079@osdn.org.ua/>
List-Archive: <http://lore.altlinux.org/devel/>
List-Post: <mailto:devel@altlinux.org>

On Tue, Oct 13, 2009 at 03:40:20PM +0800, REAL wrote:
> Но вопрос, конечно, лучше озвучить, раз он возник. Вот есть
> пакет типа libfoo-devel, там внутри статическая библиотека.
> Если возникает реформа и в этот пакет вносится
> shared-библиотека, а статическая уходит в libfoo-devel-static,
> какие конфликты/обсолеты проставлять, чтобы всё работало и спек
> не загаживался?

libfoo-devel-static Obsoletes: libfoo-devel < %change_ver
как минимум даст хинт к тому, что произошло.  Provides: не
соображу, поскольку имя libfoo-devel остаётся.

Думаю, для *-devel* это приемлемо -- всё равно при появлении
разделяемой библиотеки разломы по сборке хорошо бы чинить в
сторону её использования, а не пересовывания статики под новым
именем.

Для избежания можно было сразу делать libfoo-devel-static.
Собсно, это и прописано в секции "Статические библиотеки"
http://ftp.altlinux.org/pub/distributions/ALTLinux/Sisyphus/doc/old/rpm_packaging_howto.html

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