On Sun, Feb 22, 2004 at 10:59:08PM +0300, Mikhail Zabaluev wrote:
> Надо сказать, предложенная схема тоже не решает проблемы полностью;
> при автоматической пересборке в hasher все равно получается один
> из вариантов, два сделать можно только очень исхитрившись.
Ну, не очень. Я уже знаю как :-). Правда, блин, хак :-)

> Да и непонятно, стоит ли. Если кому-то позарез нужна сборка под
> "не тот" ABI, пусть пересобирает. В конце концов, незамороженный
Именно. Именно для того, чтобы можно было пересобирать под нужную версию
питон скопом, просто через опеределение в .rpmmacros соответствующей
переменной и последующего rpmbuild -ba ... это все и затеивалось.

> Sisyphus не предназначен для удовлетворения потребностей конечных
> пользователей.
:-) Только не говорите им об этом :-)

> Сколько сейчас пакетов, которые нужны и под 2.2, и под 2.3?
Уже не сколько. Но грядет, как говорят, 2.4 ;-)

> Может быть, имеет смысл закатать только их, вручную,
> из разных src.rpm с отличающимися spec? Точнее, предоставить
> legacy-вариант python22-%name, а вариант 2.3 оставить под родным именем?
Ну, "безобразно, зато единообразно". Я, чес-гря, тянул свои идеи, в частности,
из схемы сборки модулей perl. "Мне нравится" :-)

> При условии, что версия ABI для каждого модуля и зависимостей на него
> будет прописана жёстко, например, предложенным мной способом, проблем
> с зависимостями быть не должно.
Ну, это уже не вопрос, все понимают, что любая предложенная схема должна
в любом случае гарантировать привязку к ABI.

> Загвоздка в том, что .src.rpm не зависит от опций --with и --enable.
> Должно быть однозначное соответствие между .spec и .src.rpm,
> иначе получаются пакеты с разными именами, не отличающиеся ни
> одним байтом.
BTW, я, кажется, знаю, как сделать так, чтобы отличались :-).
Рассказывать? :-)

> Итак, я предлагаю не уродовать имена в общем случае, оставив эту
> практику для сборок отдельных модулей, по каким-либо причинам нужных
> под старый python, когда уже есть тот же модуль под новый. И уж в
> этом случае делать и отдельный .src.rpm.
В общем, тут проблема-то не в том, что есть "старый" питон, и "новый" питон.
В нормальных условиях, после переезда, есть только один питон (плюс, желающие
держать у себя _локально_ старый питон, но они сами себе злобные буратины,
хоть мы и подумаем и о них тоже).

Но проблема в том, чтобы на время _каждого_ переезда иметь возможность
сохранить в Сизифе хотя бы одну работающую версию. Как сейчас видится
переезд мне (и, надеюсь, Андрею):

	* Сборщик питона (Андрей) видит, что появилась новая версия, и
	  собирает пакет вида python-X.Z-alt*.i586.rpm

	* Кроме этого, он в АВТОМАТИЧЕСКОМ режиме собирает пакет
	  pythonXY-X.Y-alt*.i586.rpm и ВСЕ пакеты модулей, присутствующие
	  на данный момент в Сизифе как pythonXY-pyModule-*
	  
	* Затем все это хозяйство апдлоадится в Сизиф (возможно, все
	  pythonXY-* едут куда-нибудь в RPMS.obsolete или навроде этого)
	  и бросается клич: налетай, ребята!
	  
	* Ребята начинают пересобирать модули под новый питон. В какой-то
	  момент количество модулей под новый питон достигает какого-либо
	  критического значения и/или наступает "час Ч" (но он наступает
	  _не сразу_ в момент заливки нового питона!) и старый питон
	  выносится из репозитория вовсе.

Данная схема может варьироваться. Например, объявляется, что трудности
индейцев вождя не ...., и [автоматической] пересборкой модулей под старый
питон конечные пользователи Сизифа занимаются сами (хотя это было грустно,
все-таки, по факту, люди _пользуются_ Сизифом, и ставить им палки в колеса,
лишая среды разработки на месяц-другой, было бы, мягко говоря, неразумно.

Впрочем, все это не нужно будет, если, например, удастся договориться, что
с момента сборки Андреем нового питона до полной пересборки всех модулей будет
происходить, скажем, не более недели. Реально?