Alexey Tourbin пишет: > On Sun, Oct 28, 2007 at 03:56:47AM +0300, Aleksey Avdeev wrote: > >>>Если отбросить практическую причину (что программа сборки дополнительных >>>модулей в двух экземлярах так никгода и не была даже частично >>>реализована), >> >> Но _принципиальная_ возможность её реализации присутствовала. И это -- >>главное. > > > Принципиальная возможность есть всегда. > Другое дело, насколько это вписывается в дизайн репозитария. > > >>>то всё равно это никак нельзя по-нормальному сделать на >>>уровне rpm-зависимостей. То есть если /usr/bin/python висит на >>>альтернативах, то эта альтернатива динамически переключает зависимости >>>вида pythonX.Y(...) на pythonX.Z(...). Я про это в свое время много спорил. >> >>1. Можно напомнить суть споров? (Что-то не найду их в своём архиве... >>Похоже не так ищу.) >> >>2. Если не нравится /usr/bin/python на альтернативах, то может стоит >>использовать вариант взаимоконфликтующих пакетов? (В смысле: >>/usr/bin/pythonX и /usr/bin/pythonY спокойно уживаются вместе, но пакет >>содержащий /usr/bin/python может быть только один.) > > > Сумбурно отвечаю сразу на два вопроса. Если хотим иметь два питона > в репозитарии, то никак не получается нормально сделать дефолтный > /usr/bin/python. То есть нужно отказаться от /usr/bin/python ВООБЩЕ > и оставить только /usr/bin/pythonX.Y и /usr/bin/pythonX.Z. C этим пунктом согласен. > > Но отсутствие дефолтного питона явно не в интересах репозитария. И с этим -- тоже. > > ПОЧЕМУ: сейчас дефолтный питон /usr/bin/python версии 2.4 и зависимости > у пакетов имеют вид python2.4(...). Если обновить дефолтный > /usr/bin/python на 2.5, то зависимости у всех остальных пакетов никуда > не денутся, они останутся python2.4(...). Теперь подумайте, что > получается, когда питон обновился, а скрипт, запускаемый через > /usr/bin/python имеет зависимости на питон 2.4, а на самом деле в > системе стоит питон 2.5. Например, этот скрипт для работы требует > что-то типа python2.4(gtk). Но при запуске через новый /usr/bin/python > эта зависимость как бы динамически трансформируется на python2.5(gtk). > То есть зависимость может быть формально удовлетворена, но получается > пшик, скрипт не запускается потому что уже нужен gtk'шный модуль для > 2.5, а не для 2.4. Так может достаточно отделить мух от котлет? Например так: 1. В системе есть /usr/bin/pythonX.Y. И их может быть несколько. 2. В системе есть /usr/bin/python, как указатель на некоторый /usr/bin/pythonX.Y. И данная ссылка может предоставляться несколькими _взаимоконфликтующими_ пакетами. 3. При сборке пакета со скриптами использующими /usr/bin/python -- добавляем в их зависимость на пакет предоставляющий /usr/bin/python в сборочной среде. В идеале, здесь желательно иметь ручку, отключающую данное поведение: её можно использовать для получения пакетов работающих с неким диапазоном версий питонов -- возможность поставить конфликты на те версии с которыми скрипт не работает у мантейнера останется. Тогда мы имеем с гуся следующее: 1. Пакеты со скриптами использующими /usr/bin/pythonX.Y напрямую -- спокойно продолжают это делать, независимо от версии /usr/bin/python установленной в системе. 2. Если в пакете используется /usr/bin/python -- при установке будет попытка вытянуть нужную версию (ту, с которой пакет был собран). Если это приведёт к конфликтам -- ставящий будет вынужден разрешить их в ручную (и это правильно). 3. Пакет которому необходим старый питон -- для не конфликтности с новым достаточно просто пропатчить. 4. Возможно плавное замещение питона в дистрибутиве. (Но не на конкретной системе! Там, в прочем, возможен выбор _момента_ перехода.) Если я то-то не учёл -- прошу указать. > > >> Мне активно не нравиться эта идея, т. к. на практике приведёт к тому, >>что нужный для конкретного приложения питон (и само приложение) будет >>развёрнут в /home/... А это не тот стиль, который стоит >>провоцировать (приходилось сталкиваться с таким, на предыдущей работе). > > > Я делаю системное решение. То есть я исхожу из того, что все пакеты > В РЕПОЗИТАРИИ должны будут работать/починиться под новый питон. > Что там запускается из /home/user мне не особо интересно. Если там есть > что-то важное, то нужно это опакетить, и тогда придётся учитывать этот > пакет в плане миграции на питон 2.5. Этот вариант идеален, но я не чую его жизнеспособности в условиях ограниченности ресурсов. :-/ При вашем варианте имеем следующие грабли: 1. Задержка на попадание нового питона в Сизиф, пока не будет оттестировано всё, что будет сочтено "ядром питона" 2. При появлении нового питона в Сизифе -- часть приложений (что в "ядром питона" не вошла) "неожиданно" перестанет работать. 3. Калуарность тестирования нового питона (т. к. помещать его в Сизиф, пока "ядром питона" не оттестировано/портировано -- нельзя). Причём, за счёт того что для каждого использующего питон "ядром питона" своё, и с "ядром питона" коллег совпадать не обязано -- получаем источник конфликтов в рассылке... > > >> Подход, когда приложение может потребовать нужную версию питона -- >>_мне_ нравится больше. Да, он сложнее в реализации. Но это то >>направление (по интерпретируемым языкам) в котором нужно двигаться. > > > То что нам с вами нравится это иногда имеет мало отношения к реальности. > То есть нам иногда нравятся противоречивые вещи, которые, строго говоря, > по-нормальному никак нельзя совместить. Но это не значит, что таких путей искать не нужно. -- С уважением. Алексей.