ALT Linux Bugzilla – #59494

Created attachment 21629 [details]
Подробное описание решения (.md)

Created attachment 21630 [details]
Подробное описание решения (.pdf)

Описанное предложение реализовано в сборочном задании (Sisyphus): 420214
Полное описание с демонстрацией — во вложенном README.

1. В altlinux-repos — генерируются .source-файлы из имеющихся .desktop-описателей (repositories/, mirrors/) и включаются в сборку пакета. Также в сборку добавлен .category файл, нужный для отображения источников в категории "ALT Linux" в клиентских приложениях
2. В пакетах apt-conf-* — происходит копирование соответствующих .source и .category файлов из установленного altlinux-repos в /usr/share/alterator/sources/ (путь, по которому модуль Альтератора ищет файлы-описатели).

Я не очень понимаю, почему нельзя сгенерировать описатели в отдельном, собственном пакете.

Я совершенно не понимаю, зачем класть эти описатели в apt-conf-*, если их можно положить в отдельный, собственный пакет. Причём сразу все, чтобы нормальное переключение между ветками, включение и выключение gostcrypto, и т.д. могли быть реализованы простым и очевидным способом.

Я также совершенно не понимаю, какую конкретно задачу вы перед собой ставите. "Управление источниками" можно понимать и слишком узко, и слишком широко, к тому же требования имеют свойство расползаться в ширину со временем. Вы планируете заниматься переключением веток? (если нет, наверное стоит запланировать, p12 будет). Вы планируете поддержать системы, в которых системный админинстратор пользуется apt-repo, epm или vim для правки sources.list'ов?

Полноту взаимоувязки между инструментами мы обеспечить, конечно, хотим.
Сейчас мы хотим решить две задачи:

1. Обеспечить взаимоувязку с первоисточником.

altlinux-repos сейчас содержит информацию об актуальных зеркалах и описание бранчей в десктоп файлах, которые не специфированы. Перечень допустимых полей явно не описан. В текущем исправлении предложен поэтапный план перехода на новый специфицированный описатель в рамках альтератора.

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

Сценарий перехода на новые описатели:
1.1. сводим форматы, создаем source-файлы из текуших desktop-файлов;
1.2. расширяем схему source-файлов всеми полями, которые предусмотрены в текуших desktop-файлах (с ходу оказалось, что мы не предусотрели дополнительные поля для описания зеркал (прежде всего их отображаемые имена));
1.3. формируем desktop-файлы из source-файлов;
1.4. интегрируем их использование во всех инструментах.

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

Сторонний пакет сбоку эту задачу не решит.

2. Доступность.

Необходимо, чтобы при установке пакетов apt-conf-* прилетали описатели для предполагаемых к использованию бранчей.

Для apt-conf-sisyphus только сизифный.
Для apt-conf-branch - p11 и сизифный.

После выхода p12, добавим p12 для возможности обновления.

Тут стоит учесть, что altlinux-repos используется только, как пакет-справочник, из которого генерируются конкретные примеры источников в пакетах apt-conf-*. Данное исправление следует этой же логикой.

Интеграция altlinux-repos с другими пакетами планируется по мере готовности в этих пакетах такую интеграцию проводить. Мне, кроме старых модулей альтератора о такой интеграции неизвестно. Но поддержку в apt-repo хотелось получить.

Дополниьельный ряд подробностей изложен в приложении.

> 1. Обеспечить взаимоувязку с первоисточником.
> 2. Доступность.

Технически это не задачи, это требования к решению.

Приложенные pdf и md также не содержат полноценную формулировку поставленной задачи, только фрагменты решений и какие-то дополнительные параграфы, которые воспринимаются (мной) как мысли и идеи по развитию ("в будущем предлагается") а не конкретные планы.

У меня складывается впечатление, что команда Альтератора не доконца представляет себе, что делает, и к какому решению хочет прийти ("с ходу оказалось", да?). На таком этапе рано что-то "пропихивать" в системно-образующие пакеты репозитория.

Для конструктивно обсуждения предлагаю разделить дискуссию на несколько потоков.


1. Замена desktop-файлов на описатели.

Судя по "сценарию перехода на новые описатели", вы хотите именно заменить desktop-файлы на описатели на TOML, скажем так, в стиле нового Альтератора. Так почему же вы не начали эту дискусиию имено с фразы "Предлагаем заменить desktop-файлы на TOML-описатели"?

Так давайте обсудим новый формат предметно. Чем старый плох? Чем новый хорош? Примеры описания в новом и старом формате, со всеми нужными полями *сразу*, а не в формате "мы потом ещё добавим"?

Всё это в devel@?


2. План перехода на описатели.

AFAIK desktop-файлы сейчас не несут никакой ценности сами по себе, из них только генерируется apt-conf-*. В этом плане цепочка с генерацией одного в другое, другого в одно и обратно выглядит странно. Почему бы сразу не перейти на генерацию apt-conf-* из описателей, а desktop-файлы задепрекейтить и выкинуть из Сизифа?


3. Необходимость класть описатели в пакеты apt-conf-*.

Я по прежнему убеждён, что технически такой необходимости нет. Более того, текущая логика запаковки и сборки apt-conf-* в Сизиф и бранчи создаёт некоторые проблемы любым инструментам, которые захотят ей следовать, её повторить и расширить. Например, при переключении между ветками. Эти проблемы нужно устранять а не переносить в новое решение.

Мне бы хотелось увидеть, что вы всё это продумали и у вас есть план (а не "ой оказалось" с выходом p12) до того, как мы положим файлики, котороые нам потом придётся вечно поддерживать, в пакет, где они будто бы не слишком уместны.

(In reply to Ivan A. Melnikov from comment #7)
> AFAIK desktop-файлы сейчас не несут никакой ценности сами по себе, из них

Точно совершенно был какой-то модуль alterator, который смотрел в эти desktop-файлы. Но могут быть ещё пользователи.

А почему-бы не сделать список зеркал частью метаданных репозитория ? в этом случае их можно обновлять на сайте и инструмент, который их будет использовать - так же получит актуальные зеркала с сети (всё равно за обновлениями идти в сеть).

Ну и какой-то дефолт положить в систему, но не обязательно.

(Ответ для Gleb F-Malinovskiy на комментарий #8)
> (In reply to Ivan A. Melnikov from comment #7)
> > AFAIK desktop-файлы сейчас не несут никакой ценности сами по себе, из них
> 
> Точно совершенно был какой-то модуль alterator, который смотрел в эти
> desktop-файлы. Но могут быть ещё пользователи.

alterator-mirror и alterator-updates.

Предлагаю добавить в desktop файлы недостающие поля и не ломать обратную совместимость на ровном месте. Описаны недостающие ключи, неприменимость формата desktop entry не доказана.

https://altlinux.space/alterator/alterator-entry/src/branch/master/doc#%D1%81%D1%83%D1%89%D0%BD%D0%BE%D1%81%D1%82%D1%8C-%D1%82%D0%B8%D0%BF%D0%B0-source

name используется неконсистентно. Им должен быть display_name.
Переименуйте display_name в name, а name в id или в name_id.

P.S. vendorID переименуйте в vendor_id

(Ответ для Ivan A. Melnikov на комментарий #7)

> 3. Необходимость класть описатели в пакеты apt-conf-*.
> 
> Я по прежнему убеждён, что технически такой необходимости нет. Более того,
> текущая логика запаковки и сборки apt-conf-* в Сизиф и бранчи создаёт
> некоторые проблемы любым инструментам, которые захотят ей следовать, её
> повторить и расширить. Например, при переключении между ветками. Эти
> проблемы нужно устранять а не переносить в новое решение.
> 
> Мне бы хотелось увидеть, что вы всё это продумали и у вас есть план (а не
> "ой оказалось" с выходом p12) до того, как мы положим файлики, котороые нам
> потом придётся вечно поддерживать, в пакет, где они будто бы не слишком
> уместны.

По итогам обсуждения, пришли к новой схеме, в которой apt-conf-* пакеты не нужно изменять.

Работу предлагается разделить на 2 этапа - переходный и заключительный.

В переходном этапе:
- TOML-описатели .source размещаются в пакете altlinux-repos;
- .source генерируется из существующих .desktop-описателей;
- первоисточником данных временно остаются .desktop-файлы;
- генерация выполняется при сборке altlinux-repos, проверяя результат по схеме alterator-entry;
- пакет altlinux-repos самостоятельно устанавливает .source в каталог, из которого их читает модуль управления источниками.

Принадлежность репозиториев к конкретному продукту предлагается задавать не через состав apt-conf-*, а через существующие сущности .edition (редакции).
В описании редакции будет перечислен набор идентификаторов .source, доступных для этой редакции.
В таком случае, фильтрацией отображаемых источников должно заниматься клиентское приложение (например, alt-packages).

В заключительном:
- из .source временно генерируется .desktop для обратной совместимости с alterator-mirror, alterator-updates и другими существующими потребителями;
- поддержка .edition и .source встраивается в существующие инструменты управления репозиториями, прежде всего в apt-repo. Интеграция работает локально, без  D-Bus:
  apt-repo читает описание текущей редакции и использует эту информацию для фильтрации источников.
  При этом сохраняется возможность явно работать с источниками, не включёнными в текущую редакцию.

Сейчас реализован переходный этап - пример работы по такой схеме можно посмотреть в сборочном задании (Sisyphus): 432928.

- altlinux-repos генерирует .source из существующих .desktop, проверяет валидность описателей с помощью alterator-entry и устанавливает полный каталог описателей;
- alterator-entry расширяет схему .edition необязательным полем sources - список идентификаторов источников;
- alt-components-base указывает в редакциях "Альт Сервер" и "Альт Домен" относящиеся к ним источники; в пакетах редакций стоит Requires: altlinux-repos ;
- alt-packages на основе информации о редакции фильтрует список источников по следующим правилам:
	- по-умолчанию, показывает источники, перечисленные в текущей редакции, и объединяет их в отдельную категорию с названием редакции;
	  источники, не относящиеся к редакции, скрываются, но пользователь может включить их отображение через пункт «Показывать источники вне редакции»;
	  источники со съёмных носителей отображаются всегда;
	- если текущая редакция не определена или поле sources в ней отсутствует, отображаются все источники;
	- если редакция содержит отсутствующие источники, клиент выводит отдельное сообщение об их отсутствии.

(Ответ для Sergey V Turchin на комментарий #12)
> https://altlinux.space/alterator/alterator-entry/src/branch/master/
> doc#%D1%81%D1%83%D1%89%D0%BD%D0%BE%D1%81%D1%82%D1%8C-
> %D1%82%D0%B8%D0%BF%D0%B0-source
> 
> name используется неконсистентно. Им должен быть display_name.
> Переименуйте display_name в name, а name в id или в name_id.
> 
> P.S. vendorID переименуйте в vendor_id

Поле name сейчас фактически является ID сущности, уникально и используется для программной обработки. В то время как display_name - локализуемое человекочитаемое название для отображения в интерфейсе.
Теоретически name можно было бы переименовать в id, однако текущее соглашение применяется ко всем сущностям alterator entry, уже используется существующими описателями и зафиксированно в документации.

vendorID - спасибо! Уже поправили и отправили в Сизиф (alterator-entry 0.4.15-alt1)

(Ответ для alxvmr на комментарий #14)
> Теоретически name можно было бы переименовать в id, однако текущее
> соглашение применяется ко всем сущностям alterator entry, уже используется
> существующими описателями и зафиксированно в документации.
Такое лечится. Проверено на #51411 и #51839 .

А может сразу начать делать alterator3 сразу с исправлением всех проблем ДНК? ;-)