From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 24 Feb 2004 03:16:41 +0300 From: Mikhail Zabaluev To: ALT Devel discussion list Message-ID: <20040224001641.GF2598@av1046.comex.ru> Mail-Followup-To: Mikhail Zabaluev , ALT Devel discussion list References: <200402222232.27464.cray@neural.ru> <20040222214059.GA1905@av1046.comex.ru> <200402230950.40967.cray@neural.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a1QUDc0q7S3U7/Jg" Content-Disposition: inline In-Reply-To: <200402230950.40967.cray@neural.ru> User-Agent: Mutt/1.4.2.1i Subject: [devel] Re: A: =?koi8-r?b?8M/MydPJICgg0SDT18XMINfTxSDXz8XEyc7P?= ) + FAQ 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: Tue, 24 Feb 2004 00:16:43 -0000 Archived-At: List-Archive: List-Post: --a1QUDc0q7S3U7/Jg Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello Andrey, On Mon, Feb 23, 2004 at 09:50:40AM +0300, Andrey Orlov wrote: > > > Нужно решить лишь такую задачу: если есть зависимость между модулями, > > эта зависимость должна учитывать версию python ABI. Как этого можно > > достичь, я писал. > > Увы, но синтаксис языка тоже менятся, не оставаясь до конца совместимым > ни вперед, ни назад. Zope для версии 2.2 разражается кучей предупреждений > и ввалится, при запуске с 2.3, причем исключительно из-за проблем синтаксиса. Здесь ещё раз хочу предложить wrapper /usr/bin/python, который позволит устанавливать версию с помощью переменной окружения PYTHON_VERSION для любого отдельного приложения. Alternatives, как вы понимаете, такой гибкости дать не может. Нужно ли решать эту проблему с помощью вилки "ужесточение/усложнение" ("конфликтный" python vs "левый" python-weak), когда более элегантное решение есть и уже отработано на других приложениях? Ей-богу, когда пользователей зажимают в жёсткие зависимости и крюки, чтобы их обойти, это может быть гораздо хуже, чем дать им возможность ошибиться, запустив приложение не под тем python. Тем более, что это главным образом проблема ПЕРЕХОДНОГО ПЕРИОДА в Sisyphus. Обеспечение полностью безболезненного апгрейда для пользователей Sisyphus -- это вообще не-задача. > > Я думаю, можно полагаться на неявное обязательство разработчиков > > Python не ломать ABI между микро-релизами. > > Я тоже думаю, только как я уже написал - дело не в ABI, а в синтаксисе. Синтаксис тем более не меняется между микро-релизами. > > По крайней мере, такое правило должно соблюдаться: если пользователь ставит > > apt-get install python python-doc > > он вправе расчитывать на наличие всех модулей, о которых написано в > > Соблюдается. Правда, в перспективе, скорее python, python-modules, python-doc. > зависимость python / python-modules - временное решение. Предлагаю сделать постоянным. Для любителей компактной установки всё равно останется python-base и ручной выбор python-modules-* > > > python-weak -- python с облегченными зависимостями, > > > допускающий провести совместную установку со старой версий pythonX.Y > > > > Я чую ненужную сложность. > > не будет установлен. Отпустите python-weak в пространство > > невоплощённых идей. > > Не отпущу. Вам не мешает - мне нужно, некоторым другим - тоже. Кроме > того, это работает. Мне мешает любое отклонение от ожидаемого именования пакетов, которое надо запоминать или разыскивать. Аргумент "мне и некоторым другим нужно" от корифея-разработчика вызывает нехорошие подозрения. Вспоминается панель управления GNOME 1.4, 80% которой повергали обычного пользователя в ступор. Что можно сделать, если пользователь установил python-weak по недомыслию и желает его сменить на нормальный python? Апгрейдится ли python-weak и на что? Наконец, нужно ли всё это где-либо вне Sisyphus? Если ответ на последний вопрос "нет", лучше убейте этот аппендикс и уберите конфликт между python и legacy pythons. Те, кто используют Sisyphus, смогут разобраться сами, иначе им не стоит использовать Sisyphus. > Установка новой версии командой apt-get install python приведет > к сносу старой версии, из-за существующего между ними конфликта. Меня тут озарило. Нужно ввести как policy критерий использования тега Conflicts: тогда и только тогда, когда есть конфликт по файлам либо совместная установка пакетов _безусловно_ нарушает работоспособность системы или её составляющих. Если вы используете Conflicts для каких-то других целей, вы роете яму себе и другим. > > > 6. Симлинки на головные модули пакетов, устанавливаемых > > > многократно с специфичными версиями python должны управлятся посредством > > > alternatives, что позволяет избежать ситуации, с запуском головного > > > Интересно, как вы этого добьётесь, если python и инструмент > > устанавливаются раздельно и используют отдельные конфигурации > > для alternatives (slave невозможен). > > Пока что я этого добиваюсь, так как все такие пакеты мои и являются частью питона, > как например idle и pynche. С трудом представляю. При установке python заводится slave на idle, которого может не быть в системе? Без slave возможен разнобой, когда python показывает на 2.2, а idle на 2.3. > > Не стоит. Python - скриптовый язык, и пусть модули сохраняют > > скриптовый вид. Если нужна "компактность, компактность, компактность", > > пользуйтесь zip-ованными архивами, которые поддерживает python 2.3 > > Нужна не только компактность, но и быстродействие И наличие .py рядом с компилированным кодом влияет на это как? > а также некая степень > защищенности от случайного вмешательства со стороны любителя "грязной" > настройки. Учим пользователя жить в его собственной системе? :) Это настолько не в духе Unix, что я даже не знаю, что на это возразить... -- Stay tuned, MhZ JID: mhz@altlinux.org ___________ Military intelligence is a contradiction in terms. -- Groucho Marx --a1QUDc0q7S3U7/Jg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAOpfpTKqCuNPJlLgRAicbAJ9NFFaV3ZwJSffMzpwPLHr4Vp6WsQCeNpxm lM6lP+0MCzQMBUVuSg+DUUQ= =gsOU -----END PGP SIGNATURE----- --a1QUDc0q7S3U7/Jg--