Bug 1727

Summary: Репозитории для дистрибутива
Product: LINUX@Etersoft Reporter: Евгений Синельников <sin>
Component: ОбщееAssignee: Евгений Синельников <sin>
Status: DEFERRED --- QA Contact:
Severity: normal    
Priority: P5 CC: lav, rlz
Version: не указана   
Target Milestone: выпуск 1.0   
Hardware: PC   
OS: Linux   
URL: http://ftp.etersoft.ru/pub/Etersoft/LINUX@Etersoft/
Whiteboard:
Заявки RT: Связано с:
Дата напоминания:
Bug Depends on: 8910    
Bug Blocks: 1135, 1728    

Description Евгений Синельников 2008-04-18 11:25:03 MSD
Необходимо определиться с формой расширения пакетной базы.
1) Делать cвой бранч и заменять отдельные пакеты... На первый взгляд это проще... Но тогда станвиться актуальным вопрос о синхронизации с Сизифом и автоматической персборки пакетов на бранче...

2) Расширять пакетную базу новыми пакетами. При этом все открытые пакеты сразу, или постепенно, переезжают с Сизиф и бранч, а дубликаты - живут в наших репозиториях с суфиксами в именах. Иначе придётся держать  полное зеркало сизифа из-за пары наших пакетов и  вручную разрешать вопросы с обновлением и проверять каждый дубликат при обновлении.

Некой общей точкой в подходе к репозиториям хочу выбрать вот эту страничку
http://freesource.info/wiki/AltLinux/Sisyphus/SolutionProcess
где я попытался изложить те идеи, кторые ледат в основе моих рассуждений по этому вопросу. Буду рад услышать критику (лучше конструктивную) и поправки к неточностям (а также, вероятно, к заблуждениям).

По вопросу предложенных вариантов, я склоняюсь ко второму. Я пронаблюдал за тем, как хранятся репозитории в /var/ftp/pub/ALTLinux и понял что здесь проблемы те же, что и в первом варианте. Кроме того я не понял насколько часто они обновляются. При сборке образа я собирал его ещё на старом ядре (std-def-alt6), хотя у меня за день до этого уже было новое (std-def-alt7), не собирал я его и на новом инсталяторе от ldv@, поскольку он только-только попал в Сизиф.

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

Первый вариант мне не нравится по нескольким пунктам:
1) необходимо уметь устраивать полную пересборку репозитория на пакетах зависящих друг от друга... и держать совю копию этого хозяйства... Или же отказаться от неё в пользу работы на сизифе и нашем собственном его аналоге с последующем созданием собственных бранчей
2) необходимо держать свои зеркала и делать многогигабайтный дубль слегка переделанного сизифа, что мне кажется излишеством. Кроме того, что это дорого, оно ещё и не эффективно в силу того, что репозитории Сизифа уже есть у людей. И тянуть ещё его один клон нет никакого резона.

Реализацию второго варианта я вижу в таком виде, чтомы не трогаем оригинаьный набор пакетов из сизифа и бранчей, а расширяем их своими. Новые свободнораспространяемые пакеты мы сразу помещаем в сизиф, дополнительные же исправления держим так, что они ставятся под другими именами, но предоставляют по зависимостям исходныем имена. Например kdesbase у нас kdebase-etersoft и все го бинарные подпакеты тоже соответственно kdebase-*-etersoft. При этом каждый из них предоставляет соотвествующие имена вида:
kdebase-* = %origversion
где %origversion - либо текущая версия пакета, если мы её не меняли, либо исходный вариант, который ожидается пакетами, зависящими от данного. Конфликты пакетов одновременно предоставляющие одинаковые имена (например по библиотекам) мы будем разрешать с помощью pkgpriorities в apt. Для этого уже существует специальный набор пакетов apt-conf-* У нас будет apt-conf-etersoft.
Comment 1 Евгений Синельников 2013-02-12 21:55:50 MSK
Собрал apt-conf-etersoft-6.0-eter1 для p6 в рамках стратегии расширять пакетную базы на основе бранчей ALT Linux.

Требуется обосновать применение apt-conf пакетов в дистрибутивах на базе ALT Linux Platform 6 (в будущем 7 и т.д.) и тестовых решений на базе ALT Linux Sisyphus. Главный вопрос, при выборе apt-conf пакетов - это обновляемость.

Нужно описать различные варианты обновляемых решений и выбрать оптимальный подход с минимальными рисками для конечного пользователя.
Comment 2 Евгений Синельников 2013-02-14 20:32:12 MSK
Для завершения задачи нужно перейте на новую схему генерации x86_64-i586 пакетов с помощью нового arepo.
Comment 3 Vitaly Lipatov 2014-09-11 18:45:19 MSK
Откладываем задачи, к которым не обращались более 100 дней.