раздача собственного питона, кросс-линукса

Question

У меня следующая проблема. Мне нужно распространять нашу собственную версию Python с магией. Для этого необходимо выполнить следующий процесс:

1. Я создаю интерпретатор Python (на Redhat Linux)
2. установить его где-нибудь
3. tar.gz все это
4. когда пришло время создать пакет пользователя, распакуйте tar.gz в каталог, который станет пакетом пользователя
5. tar.gz каталог пользовательских пакетов
6. разместите tar.gz в сети

Это метод, который я должен использовать. Хорошо плохо? Я не знаю, у меня мало опыта в качестве упаковщика, и в любом случае я не могу предложить изменения. Так было всегда.

Оказывается, что когда пользователь распаковывает этот tar.gz в suse и пытается запустить python setuptools (который был установлен вместе с python), модуль hashlib вызывает исключение. Я обнаружил, что при создании python на redhat скрипт настройки python находит библиотеку openssl, которая, в свою очередь, заставляет пропустить сборку shamodule.c, md5.c и т. Д. И компилирует hashmodule.c для подключения к библиотека openssl. очевидно, что openssl 0.9.7 для suse и 0.9.8 для redhat несколько отличаются, это означает, что по какой-то причине модуль _hashlib при импорте в suse вызывает ошибку импорта, в результате чего hashlib пытается импортировать _md5, _sha, _sha256, которых там нет, потому что на redhat не было причин их компилировать (так как openssl там был очень хорош).

Кто-нибудь знает, как решить эту проблему. Как я уже сказал, мой опыт работы с упаковщиком - это минимум, поэтому любые подсказки и предложения приветствуются, и я постараюсь развернуть их настолько, насколько позволит наше наследие.

Answer 1

Кто-нибудь знает, как решить эту проблему.

Ты не можешь, правда. Если проблема не в библиотеке OpenSSL, это может быть сама библиотека C или какой-то другой критический компонент. Ваши лучшие решения:

(A) Создайте версию Python для каждой операционной системы, которую вы хотите поддерживать, или

(B) Переработайте ваш код, чтобы использовать нативный системный Python на каждой платформе.

Ваша альтернатива - создать полностью автономную среду сборки, чтобы при сборке под RedHat вы не использовали библиотеку system OpenSSL, а вместо этого использовали библиотеку, которую вы создали сами. Это будет работать практически для всего, кроме библиотеки C, но это может быть сложно настроить. Идея состоит в том, чтобы минимизировать отношения между вашим пакетом и системными библиотеками.

Если вы поддерживаете только RedHat и SUSE, вы, возможно, можете использовать опцию (A), создав соответствующий файл спецификации и создав двоичные пакеты для каждой платформы. Это был бы хороший способ упаковать все.

Answer 2

Вы должны рассмотреть вопрос о распространении RPM с исходным кодом вашей версии Python, а не двоичного архива.Вы можете взять существующий выпуск Python и перепаковать его с патчем своих изменений.Подробнее о том, как это сделать, можно узнать из книги RPM .