[Devel] Проблема совместимости нового дистрибутива и репозитариев AltLinux

[Evgeny Sinelnikov]

Здравствуйте,

2008/3/15 Dmitry M. Maslennikov <maslennikovdm на gmail.com>:
> Если я правильно понимаю поставленные перед нами задачи, то мы делаем
>  некоторый новый дистрибутив (как кстати он будет называться?)

Рабочее название Linux на Etersoft.... А дальше, как решит 1С, как я понимаю...

>  на основе
>  AltLinux.
>  Меня, во-первых, интересует, чем этот новый дистрибутив будет на самом деле
>  отличаться от AltLinux. Будет ли он ориентирован исключительно на Desktop?

Насколько я понмаю, да...

>  Во-вторых, очень интересна проблема совместимости со репозитарием AltLinux.
>  Если мы только добавим в сборку новые пакеты, то в этом случае никаких
>  проблем нет. Но ведь мы собираемся и заменить некоторые пакеты, при этом
>  заметно поменяв их функциональность, например пакеты которые обеспечивают
>  загрузку системы (с помощью init-ng). Как обеспечить, что пользователю при
>  обновлении не приедет из Сисифа, что-либо, что нарушит функциональность
>  системы?

Тут есть два принцииальных подхода...
1) Кидать результаты пересекающихся задач и пакетов в апстрим, для нас
это, отчасти, ALT Linux.
2) Держать свою базу

Поскольку мы планируем добавлять обновлённые пакеты, нам потребуется 2
вариант. Но, тем не менее, мы планируем максимально, что можем,
продвигать по варианту 1 - это должно уберечь нас от необходимости
постоянной синхронизации всех наших пакетов.

Самый идеальный вариант, при создании дистрибутива-саттелита - это,
конечно, собственная не пересекающаяся по именам пакетная база. Я вот
думаю, что это стоит обдумать... Например, тот же startup. В случае,
если этот пакет будет полностью наш и в альтах останется свой. Проще
назвать его startup-etersoft и сделать провайдинг из этого пакета
startup = %version-%release. Тогда при обновлении он не будет
обновляться альтовским и тот не снесёт нашего... Когда же наш пакет
будет перенесён в Альты там достаточно будет сделать Obsolete:
startup-etersoft <= last-version и Conflicts startup-etersoft <=
last-version. Версия здесь важна, чтобы повторить эту же штуку в
будущих версиях, если понадобиться...
С Федорой нами этот вариант не рассматривался, по двум причинам.
Во-первых, людям не нравились не гламурные имена пакетов с суффиксом,
во-вторых, вопрос о пробросе результатов обратно не ставился совсем,
скорее наоборот....
Такой подход, с новыми именами, позволит держать с поисках апта и
наши, и их репозитрии не боясь перекрытия наших пакетов новыми от
альтов.

Это идея у меня была ранее, и пока я придумавал ответ, снова пришла в голову.
2lav: просьба оценить степень кривости предложения. Если никто не
возражает прошу сразу принять идею на ворружение, пока ещё ничего
далеко не уплыло. Со своей стороны могу сказать, что у апта есть
несколько средств. Ну, может и так пригодится... Я только недавно о
них узнал, когда понял как всё это дело обходят при создании образов.

>  Когда мы делали дистрибутив на основе Fedora, то быстро пришли к тому, что для
>  стабильного существования системы необходимо держать свой репозитарий
>  аналогичный репозитарию Fedora, который обновляли мы сами под своим
>  контролем, а пользователи могли обновляться только из него. Будем ли мы
>  делать так же? Или возможности apt позволяют как-то стабилизировать
>  обновления, чтобы чужие пакеты точно не вмешались в наши? (на yum нам такого
>  не удалось)
>  И еще один вопрос: планируем ли мы, и если да, то насколько полно,
>  бакпортировать наши изменения в AltLinux?

Я полагаю наиболее полно.... То есть всё, что ты собирёшь для Димы по
startup желательно отдать ему же, причём таким образом, чтобы он смог
запустить его в старом режиме. Как один из вариантов, потребуется
пакет startup-common, но лучше бы этого добиться без введения
дополнительных сущностей, если это возможно...

-- 
Sin (Sinelnikov Evgeny)