[devel] (was: Python Modules Policy)

[Andrey Orlov]

On Monday 16 February 2004 11:46, Andrey Orlov wrote:
> Пункты 2, 3 разрушают юзабельность решения с поддержкой и менеджментом
> пакетов, основанной на использовании APT / RPM. Я крайне сожалею, но я
> против. Подробности опять-таки в отдельном письме.

Краткое описание :

    Я поразмышлял над текущей ситуацией и вариантами ее улучшения и считаю,
    что любое из предложенных изменений ее ухудшает по объективными
    признакам.  Поэтому, единственное изменение которое предлагается
    оставить - это ввести ограничение на одновременную установку python22 /
    23.
    
Признаки, по которым сравниваются альтернативы :

    С точки зрения администрирования и использования ALTLinux, использование
    apt/rpm предоставляется следующие безусловно ценные возможности :
    
        1.  Состоятельность ограничений -- т.е. в любом валидном состояннии
            ограничений каждый пакет получает для своей работы необходимую
            среду;
            
        2.  "Выводимый" апгрейд -- Список пакетов, которые будут установлены
            после апгрейда системы может быть получен автоматически, т.е.
            без вмешательства оператора, на основе текущего состояния
            системы и репозитория;
            
    Сразу замечу, что отказ от любой из этих возможностей ставит под
    сомнение необходимость и возможность эксплуатации решений, основанных на
    apt/rpm.
    

Текущая ситуация ограничений на python и модули к нему:

    1.  Есть два альтернативных пакета python (python22 & python23);
    
    1'. Необязательное ограничение на одновременную установку  python22 &
    python23;

    2.  Все модули существуют в единственном варианте, собранные под один из
        пакетов python;
    
    3.  В модулях явно прописана зависимость на используемый пакет python;
    
    4.  Существуют целевые программы (например Zope), в единственном
        варианте, требующие один из пакетов python;
    
    
    Применим признаки сравнения :
    
        1.  При условии наличия ограничения 1', система ограничений
        состоятельна;
            
        2.  Апгрейд выводим (как пример - из рабочего сервера под master22,
            использующего Zope + python22 + MySQLdb + и т.п. я без малейших
            проблем командой apt-get upgrade получил сервер под сизиф, исползующий
            Zope + python23 + MySQLdb + и т.п., и собираюсь тоже самое проделать
            во вторник на другом сервере);
        
        
Введение многократно-собираемых пакетов :

    1.  Есть два альтернативных пакета python (python22 & python23)
    
    2.  Все модули существуют в двух вариантах, под каждый пакет python;
    
    3.  В модулях явно прописана зависимость на используемый пакет python;
    
    4.  Существуют целевые программы (например Zope), в единственном
        варианте или множественном вариантах, требующих один из пакетов
        python;

    Применим признаки сравнения :
    
        1.  Система ограничений состоятельна;
        
        2.  Апгрейд не выводим (как альтернатива примеру из предыдущего раздела -
            потребуется явная ручная установка всех парных пакетов, что для того сервера
            привело бы к отдаче 10ти команд apt-get install ..., оно конечно не трудно, 
            но нафига тогда apt вообще нужен?);

    Кроме того, необходимо отметить, что первый признак удовлетворяется
    _только_ при безусловной пересборке всех модулей под оба питона и
    оттестированности результатов этой пересборки.

Сравнение результатов и размышления о :

   Текущее состоянии сохранияет оба признака, предлагаемое - однозначно
   разрушает второй признак и ставит под большое сомнение выполнение первого
   признака.
   
   Разрулить это можно усилив требование 4 до формулировки "Существуют
   целевые программы (например, Zope) в единственном варианте, содержащим
   зависимости на все модули, которые могут быть им использованы", что для
   такого пакета как Zope, вообще говоря, представляется крайне не
   эффективным, если вообще возможным.
   
   Нельзя не упомянуть возможный вариант решения, основанный на кляузе
   Obsoleted добавляемой в каждый из пакетов-модулей. Я поэксперементировал
   над этим, во-1-ых автоматического апгрейда не происходит, во-2-ых некая
   якобы ценная возможность (из-за которой, собственно, все и началось), под
   названием "возможность одновременного использования python22 / 3"
   теряется безвозвратно (т.е. rpm позволяет поставить оба пакета, но apt
   этого не понимает)..

   В заключении упомянем требование 1' : мне удалось сделать это ограничение
   "мягким", введя два пакета: pythonX.Y-strict & pythonX.Y-weak. Установка
   пакета *-weak позволяет держать установленным предыдующий питон, конечно,
   состоятельность при этом не гарантируется: т.е. решение для тех кто готов
   принять риск. Подробнее об этом см. в письме про python
    
Заключение :

    Я против введения схемы именования модулей для python, основанной на
    введении префикса версии интерпретатора, так как при этом apt / rpm,
    и, как следствие, сам Сизифус, становятся малоюзабельными. Возможное 
    решение желающим работать со старыми модулями python - создать отдельный 
    репозиторий, куда перекладывать старый пакет при выходе пакета, собранного 
    с новой версией. Насколько это реально нужно - зависит от наличия реальной
    необходимости работы с питоном старых версий в среде сизифус, лично я к
    такой необходимости отношусь очень скептически.
     
-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray на neural.ru, jid: cray на altlinux.org ---
----------------------------------------