ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: Vitaly Kuznetsov <vitty@altlinux.ru>
To: Igor Vlasenko <vlasenko@imath.kiev.ua>
Cc: "Денис Смирнов" <mithraen@freesource.info>,
	"ALT Linux Team development discussions"
	<devel@lists.altlinux.org>
Subject: Re: [devel] GHC-7.4
Date: Fri, 10 Feb 2012 08:44:45 +0400
Message-ID: <c6d8a8d21d3b0fec03b84d04c3bcc49f@hadoop.ru> (raw)
In-Reply-To: <20120209212250.GA28583@dad.imath.kiev.ua>

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. Спеки же самих пакетов можно не 
менять.



  reply	other threads:[~2012-02-10  4:44 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-06  6:34 Vitaly Kuznetsov
2012-02-06  8:22 ` Денис Смирнов
2012-02-06 10:01   ` Vitaly Kuznetsov
2012-02-06 13:51     ` Денис Смирнов
2012-02-06 15:32       ` Igor Vlasenko
2012-02-08 22:28         ` Денис Смирнов
2012-02-09 21:22           ` Igor Vlasenko
2012-02-10  4:44             ` Vitaly Kuznetsov [this message]
2012-02-10 16:49               ` Igor Vlasenko
2012-02-10 17:54                 ` Igor Vlasenko
2012-02-10 22:52                   ` Денис Смирнов
2012-02-10 23:04                     ` Igor Zubkov
2012-02-10 23:40                       ` Денис Смирнов
2012-02-11 18:54                     ` Igor Vlasenko
2012-02-12 21:32                       ` Денис Смирнов
2012-02-13 15:06             ` Денис Смирнов
2012-02-13 19:17               ` Igor Vlasenko
2012-02-14 12:19                   ` Igor Vlasenko
2012-02-14 12:46                     ` Igor Vlasenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c6d8a8d21d3b0fec03b84d04c3bcc49f@hadoop.ru \
    --to=vitty@altlinux.ru \
    --cc=devel@lists.altlinux.org \
    --cc=mithraen@freesource.info \
    --cc=vlasenko@imath.kiev.ua \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git