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: Mon, 13 Feb 2012 21:17:02 +0200 From: Igor Vlasenko To: ALT Linux Team development discussions Message-ID: <20120213191702.GA8608@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> <20120213150629.GA27305@t60p.mithraen.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120213150629.GA27305@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: 7B8A94B03E1.AC862 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: Mon, 13 Feb 2012 19:17:12 -0000 Archived-At: List-Archive: List-Post: Сорри, приболел, реагирую с запаздыванием. On Mon, Feb 13, 2012 at 07:06:30PM +0400, Денис Смирнов wrote: > IV> Подумав еще раз, выбрал и хочу предложить следующее: > IV> Каждое приложение (вроде xmonad) в установленной системе одно, > IV> Библиотек (вроде ghc-zlib) в системе может быть несколько, > IV> неконфликтующих, равноправных, с названиями > IV> ghcXYZ(.T)-zlib, где XYZ - версия ghc, .T -serial (обычно %nil). > IV> требующих каждая свой ghcXYZ(.T). ghc при этом придется перевести > IV> на альтернативы. > > Для чего serial? Для следующего, прошу поправить, если не так понимаю. Даже если версия XYZ не изменилась, при необходимости внести изменения в ghc полетят его provides - diff -u rebuild_provides sisyphus_provides ... ghc7.0.1(time) = 1.2.0.3 -ghc7.0.1(time-1.2.0.3-edf96900354f64de48284c95dbf6029a) +ghc7.0.1(time-1.2.0.3-9dc693ae41bc4a79faf2339f8923a2c4) ghc7.0.1(unix) = 2.4.1.0 -ghc7.0.1(unix-2.4.1.0-13f44222715caac4bba717310d1dd2e6) +ghc7.0.1(unix-2.4.1.0-f61f2ddea759757341ca757be499cab8) ghc = 7.0.1-alt1 и т.д. И для нового релиза ghcXYZ придется вместе с ним пересобирать все пакеты, а мы пытаемся уйти от гигантских транзакций. Вот чтобы и не требовалась тотальная пересборка, и нужен ghc_serial, который по умолчанию %nil и не виден, но если понадобится (например, с патченным ghc сборка чего-то отвалилась) то он есть. > IV> У приложений будет написано > IV> BuildRequires: %{ghcdep zlib utf8-string ...} > IV> которые в зависимости от содержимого rpm-build-ghc > IV> будут при сборке раскрываться в конкретные > IV> ghcXYZ(.T)-zlib, ghcXYZ(.T)-utf8-string, ghcXYZ(.T)-... > > Да, это важно для сборки приложений (вроде xmonad). > > Для остального -- так как версия ghc также будет и в %name, то можно в > buildrequires обойтись без макросов а указывать конкретные пакеты. Согласен. > IV> Затем меняем rpm-build-ghc и неспеша пересобираем приложения. > Гм, а почему меняем rpm-build-ghc? Ради ghcdep? Ну да. мы же теперь хотим, чтобы он раскрывался в новое значение. > IV> Те приложения, которые с новым набором ghc+libs собираться > IV> упорно не хотят, оставляем собираться со старым набором, > IV> явно загружая при сборке rpm-build-ghc-compat-ABC(.D). > Скорее юзая макрос типа %set_ghc_version (по аналогии с gcc). Поддерживаю любую реализацию. -- Dr. Igor Vlasenko -------------------- Topology Department Institute of Math Kiev, Ukraine