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=-1.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_WEB,SPF_PASS autolearn=no version=3.2.5 Date: Thu, 9 Feb 2012 23:22:50 +0200 From: Igor Vlasenko To: ALT Linux Team development discussions Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120208222823.GA18828@t60p.mithraen.ru> User-Agent: Mutt/1.5.21 (2010-09-15) X-imath-kiev-ua-MailScanner-Information: Please contact the ISP for more information X-imath-kiev-ua-MailScanner-ID: A78894B0412.AEBD6 X-imath-kiev-ua-MailScanner: Found to be clean X-imath-kiev-ua-MailScanner-From: vlasenko@imath.kiev.ua Cc: =?utf-8?B?0JTQtdC90LjRgSDQodC80LjRgNC90L7Qsg==?= , Vitaly Kuznetsov 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: Thu, 09 Feb 2012 21:23:05 -0000 Archived-At: List-Archive: List-Post: On Thu, Feb 09, 2012 at 02:28:23AM +0400, Денис Смирнов wrote: > On Mon, Feb 06, 2012 at 05:32:55PM +0200, Igor Vlasenko wrote: > IV> Хотел бы предложить помощь. Могу заскриптовать работу с srpm пакетами > IV> для поддержки нескольких версий ghc. Еще в прошлом году собирался > IV> так сделать, но попал в положение Буриданова осла, когда > IV> было несколько вариантов, как это будет выглядеть на практике, > IV> со своими достоинствами и недостатками, и так и не выбрал, как > IV> должно выглядеть multighc полиси. > IV> Т.е. надо выбрать схему работы, а я ее с удовольствием заскриптую. > > А какие варианты ты преддполагаешь? Подумав еще раз, выбрал и хочу предложить следующее: Каждое приложение (вроде 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). Инструменты для автоматизированной правки спеков я напишу и предоставлю. Как такой вариант? -- Dr. Igor Vlasenko -------------------- Topology Department Institute of Math Kiev, Ukraine