На базе нового Альтератора выпущен модуль управления источниками, позволяющий управлять репозиториями через клиентские приложения (например, alt-packages). Модуль предоставляет полный функционал только для источников, имеющих файлы-описатели в формате TOML (.source). Без .source-описателя репозиторий не отображается в интерфейсе и недоступен для управления. Предлагаю добавить в altlinux-repos генерацию .source-файлов из имеющихся .desktop-описателей (repositories/, mirrors/). Сгенерированные файлы будут установлены как часть пакета и доступны пакетам apt-conf-* для установки в /usr/share/alterator/sources/ (путь, по которому модуль ищет файлы-описатели). Ссылка на спецификацию файлов .source: https://altlinux.space/alterator/alterator-entry/src/branch/master/doc#сущность-типа-source
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.
