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: Fri, 10 Feb 2012 18:49:30 +0200 From: Igor Vlasenko To: ALT Linux Team development discussions Message-ID: <20120210164930.GA20757@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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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: 3C6B54B03CC.AE6AD 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: Fri, 10 Feb 2012 16:49:40 -0000 Archived-At: List-Archive: List-Post: On Fri, Feb 10, 2012 at 08:44:45AM +0400, Vitaly Kuznetsov wrote: > Мне непонятно, откуда в этой схеме будет появляться несколько версий > одной библиотеки. Они будут собираться из разных исходных пакетов? Да. Основное различие в значениях макросов GHC_VER, и опционально, GHC_SERIAL (обычно %nil; нужен, если вдруг придется собирать несколько поколений с одной версией ghc). > Если я правильно понял Дениса, то хочется получить следующий workflow: > 1) Вышел новый ghc - собираем в репозиторий его и > rpm-build-ghc-whatever > 2) По одной пересобираем библиотеки с новым ghc (и вот тут как раз > должны рождаться 2 версии) > 3) Пересобираем приложения, проверяем что старые библиотеки никому > не нужны > 4) Пересобираем библиоткеки ещё раз, оставляем только новую версию. В предложенной схеме в пункте 4 нет необходимости. Можно просто удалить старые библиотеки. А можно и не удалять. > В предложеной схеме, если я правильно понял, на шаге 2 нужно будет > автоматизированным способом создать клоны исходных пакетов с > библиотеками. Да, + еще автоматизированно обновляться из Hackage и инструменты подготовки транзакций для заливки. > Можно, наверное, пойти другим путём: собирать все возможные версии > библиотеки (точнее - все, которые собираются) из одного спека. При > этом потребуется устроить циклы в %build и %install, ну да это не > сложно. Это подход к автоматизации, при которой мы по сути хотим хранить скрипты автоматизации в спек файле. IMHO, это не эффективно, так как придется руками хардкодить списки и т.д., внешние скрипты эффективнее, IMHO. > Можно также предположить, что почти всё с новым ghc собирается. Это > означает, что нужно лишь придумать возможность собрать > compat-библиотеку и держать в Сизифе несколько ghc. Спеки же самих > пакетов можно не менять. Я тоже сначала думал о таких подходах, но если спеки самих пакетов не менять, то у нас сразу же возникает шаг 4) выше -- обязательная всеобщая пересборка. А всеобщая пересборка -- вещь очень коварная, когда семеро одного ждут. Если у нас 20 ghc пакетов -- этот аспект не заметен. Если у нас 90 ghc пакетов, как сейчас - это еще терпимо. Но если у нас будет 900 ghc пакетов (не обязательно в Сизифе; может быть, в отдельной песочнице автоимпорта из Hackage) то необходимость всеобщей пересборки на шаге 4) обязательно выстрелит в ногу и рано или поздно парализует работу. Вспомним героические усилия для обновления питона. -- Dr. Igor Vlasenko -------------------- Topology Department Institute of Math Kiev, Ukraine