From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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=unavailable version=3.2.5 To: Igor Vlasenko X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 10 Feb 2012 08:44:45 +0400 From: Vitaly Kuznetsov In-Reply-To: <20120209212250.GA28583@dad.imath.kiev.ua> References: <20120206082218.GA1725@t60p.mithraen.ru> <20120206135149.GA22824@t60p.mithraen.ru> <20120206153255.GA8570@dad.imath.kiev.ua> <20120208222823.GA18828@t60p.mithraen.ru> <20120209212250.GA28583@dad.imath.kiev.ua> Message-ID: X-Sender: vitty@altlinux.ru User-Agent: Roundcube Webmail/0.5.3 Cc: =?UTF-8?Q?=D0=94=D0=B5=D0=BD=D0=B8=D1=81_=D0=A1=D0=BC=D0=B8=D1=80=D0=BD?= =?UTF-8?Q?=D0=BE=D0=B2?= , ALT Linux Team development discussions Subject: Re: [devel] GHC-7.4 X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 04:45:00 -0000 Archived-At: List-Archive: List-Post: On Thu, 9 Feb 2012 23:22:50 +0200, Igor Vlasenko wrote: > Подумав еще раз, выбрал и хочу предложить следующее: > > Каждое приложение (вроде xmonad) в установленной системе одно, > Библиотек (вроде ghc-zlib) в системе может быть несколько, > неконфликтующих, равноправных, с названиями > ghcXYZ(.T)-zlib, где XYZ - версия ghc, .T -serial (обычно %nil). > требующих каждая свой ghcXYZ(.T). ghc при этом придется перевести > на альтернативы. > > Виртуальных Provides: вида ghc-zlib НЕ БУДЕТ. Вместо этого > BuildRequires: будут вычисляться при сборке, макросом. > > У приложений будет написано > BuildRequires: %{ghcdep zlib utf8-string ...} > которые в зависимости от содержимого rpm-build-ghc > будут при сборке раскрываться в конкретные > ghcXYZ(.T)-zlib, ghcXYZ(.T)-utf8-string, ghcXYZ(.T)-... > > При обновлении сначала неспеша собираем новый ghc и библиотеки к > нему. > Затем меняем rpm-build-ghc и неспеша пересобираем приложения. > > Те приложения, которые с новым набором ghc+libs собираться > упорно не хотят, оставляем собираться со старым набором, > явно загружая при сборке rpm-build-ghc-compat-ABC(.D). > > Инструменты для автоматизированной правки спеков я напишу и > предоставлю. > > Как такой вариант? Мне непонятно, откуда в этой схеме будет появляться несколько версий одной библиотеки. Они будут собираться из разных исходных пакетов? Если я правильно понял Дениса, то хочется получить следующий workflow: 1) Вышел новый ghc - собираем в репозиторий его и rpm-build-ghc-whatever 2) По одной пересобираем библиотеки с новым ghc (и вот тут как раз должны рождаться 2 версии) 3) Пересобираем приложения, проверяем что старые библиотеки никому не нужны 4) Пересобираем библиоткеки ещё раз, оставляем только новую версию. В предложеной схеме, если я правильно понял, на шаге 2 нужно будет автоматизированным способом создать клоны исходных пакетов с библиотеками. Можно, наверное, пойти другим путём: собирать все возможные версии библиотеки (точнее - все, которые собираются) из одного спека. При этом потребуется устроить циклы в %build и %install, ну да это не сложно. Можно также предположить, что почти всё с новым ghc собирается. Это означает, что нужно лишь придумать возможность собрать compat-библиотеку и держать в Сизифе несколько ghc. Спеки же самих пакетов можно не менять.