From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 23 Feb 2004 07:20:37 +0600 From: Alexey Morozov To: Mikhail Zabaluev , ALT Devel discussion list Subject: Re: [devel] Re: Q: Python packaging howto Message-ID: <20040223012037.GB15141@localhost.localdomain> References: <20040220120041.GA2684@av1046.comex.ru> <20040221113726.GB29390@pyro.hopawar.private.net> <20040221182533.GB14716@av1046.comex.ru> <20040221191444.GA3719@nomad.office.altlinux.org> <20040222002659.GC15706@localhost.localdomain> <20040222195908.GA1865@av1046.comex.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qcHopEYAB45HaUaB" Content-Disposition: inline In-Reply-To: <20040222195908.GA1865@av1046.comex.ru> User-Agent: Mutt/1.4.2.1i Cc: X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 01:19:39 -0000 Archived-At: List-Archive: List-Post: --qcHopEYAB45HaUaB Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit 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 или навроде этого) и бросается клич: налетай, ребята! * Ребята начинают пересобирать модули под новый питон. В какой-то момент количество модулей под новый питон достигает какого-либо критического значения и/или наступает "час Ч" (но он наступает _не сразу_ в момент заливки нового питона!) и старый питон выносится из репозитория вовсе. Данная схема может варьироваться. Например, объявляется, что трудности индейцев вождя не ...., и [автоматической] пересборкой модулей под старый питон конечные пользователи Сизифа занимаются сами (хотя это было грустно, все-таки, по факту, люди _пользуются_ Сизифом, и ставить им палки в колеса, лишая среды разработки на месяц-другой, было бы, мягко говоря, неразумно. Впрочем, все это не нужно будет, если, например, удастся договориться, что с момента сборки Андреем нового питона до полной пересборки всех модулей будет происходить, скажем, не более недели. Реально? --qcHopEYAB45HaUaB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAOVVlX5DZdJn19V0RAhABAJ9L1FjRXhE8R4mg8OWGWp0juzrzjgCfXR8P 5t6zd8crjRstxdzoS+30+GA= =b52F -----END PGP SIGNATURE----- --qcHopEYAB45HaUaB--