Для работы инстурментария, сканирующего систему на уязвимости, нужно точно знать репозиторий (версию, имя), с которого данная система получает обновления. У меня сейчас и уже очень давно sisyphus, но в /etc/os-release до сих пор сказано: $ cat /etc/os-release NAME="ALT" VERSION="10.1" ID=altlinux VERSION_ID=10.1 PRETTY_NAME="ALT Workstation K 10.1 (Sorbaronia Mitschurinii)" ANSI_COLOR="1;33" CPE_NAME="cpe:/o:alt:kworkstation:10.1" BUILD_ID="ALT 9.2 " HOME_URL="https://www.basealt.ru/" BUG_REPORT_URL="https://bugs.altlinux.org/" DOCUMENTATION_URL="https://docs.altlinux.org/" SUPPORT_URL="https://support.basealt.ru/ Хотя видно, что когда-то давным давно был установлен ALT 9.2
Аналогичный вопрос для всех веток - где-то должна быть информация о бранче.
Т.е. - вообще алгоритм работы нужен такой: я поставил дистрибутив и обновляюсь из stable - у меня в /etc/os-release указан дистрибутив, источник обновления - имя stable бранча. В идеале ещё добавлять дату последней установки обновлений (или дату репозитория, из которого устанавливались обновления). При переходе с ветки на ветки информация о том, что у меня установлен stable дистрибутив должна стать неактуальной. Кстати, в примерах: https://www.freedesktop.org/software/systemd/man/os-release.html можно заводить свои поля, хотя на мой взгляд достаточно и существующих.
В файле os-release усть строка "CPE_NAME". Для K Workstation эта строка судя по всемупрописана в пакете branding-xalt-kworkstation-release-*. А где прописаны эти CPE для остальных продуктов?
У меня Сизиф, но брендинг стартеркита: $ cat /etc/os-release NAME="starter kit" VERSION="p10 (Hypericum)" ID=altlinux VERSION_ID=p10 PRETTY_NAME="ALT Starterkit (Hypericum)" ANSI_COLOR="1;33" CPE_NAME="cpe:/o:alt:starterkit:p10" HOME_URL="http://en.altlinux.org/starterkits" BUG_REPORT_URL="https://bugs.altlinux.org/" BUILD_ID="starter kit p10 (Hypericum)" Мы можем при сборке брендинга выставлять значение репозитория примерно так: https://git.altlinux.org/gears/b/branding-alt-spserver.git?p=branding-alt-spserver.git;a=commitdiff;h=38c86798b07e325f26c2b0518278715be0998487;hp=3b61efbf752309f38fa2e5cd19ca3c28fb29c28e в любых частях брендинга. Но на e2k не работает rpm --eval %_priority_distbranch https://bugzilla.altlinux.org/44626
да, мне тоже нравится идея в os-release добавлять произвольное поле ALT_BRANCH_ID и в него записывать %_priority_distbranch Только предлагаю это делать через branding пакеты, которые при сборке для бранча будут к себе записывать куда-то в бинарный пакет %_priority_distbranch Тогда при обновлении с p10 до sisyphus этот самый бинарный пакет обновится и перепишет ALT_BRANCH_ID Но нужно будет пересобирать эти пакеты после бранчевания.
Необходимо привести записи CPE_NAME в файле к одному виду и определиться с версионированием Сейчас в стартеркитах докер-контейнерах написано: CPE_NAME="cpe:/o:alt:starterkit:p10" В СП8: CPE_NAME="cpe:/o:alt:spserver:8.4" CPE_NAME="cpe:/o:alt:spworkstation:8.4" В Workstation K так: CPE_NAME="cpe:/o:alt:kworkstation:10.1" В Simply: CPE_NAME="cpe:/o:alt:slinux:9.1" CPE_NAME="cpe:/o:alt:slinux:10.1" Предлагаю: - Для стартеркитов (и осованных на них докер-образах) поменять поле версии р10 на 10. Насколько мне исвестно этот момент уже обсуждался с Антоном Мидюковым. - Для обычных продуктов убрать минорную версию из СРЕ (10.1, 10.2,... -> 10) - Для СП8 оставить как есть, т.к. 8.3 и 8.4 это разные продукты. Корректность и единообразие СРЕ на самом деле важно для обеспечения однозначной идентификации целевой ОС при обработке информации об уязвимостях.
(Ответ для Danil Shein на комментарий #6) > Необходимо привести записи CPE_NAME в файле к одному виду и определиться с > версионированием > > Сейчас в стартеркитах докер-контейнерах написано: > CPE_NAME="cpe:/o:alt:starterkit:p10" > > В СП8: > CPE_NAME="cpe:/o:alt:spserver:8.4" > CPE_NAME="cpe:/o:alt:spworkstation:8.4" > > В Workstation K так: > CPE_NAME="cpe:/o:alt:kworkstation:10.1" > > В Simply: > CPE_NAME="cpe:/o:alt:slinux:9.1" > CPE_NAME="cpe:/o:alt:slinux:10.1" > > > Предлагаю: > - Для стартеркитов (и осованных на них докер-образах) поменять поле версии > р10 на 10. Насколько мне исвестно этот момент уже обсуждался с Антоном > Мидюковым. Да. Но давайте уточним. Сейчас версия p10 у пакета, так что VERSION=p10 VERSION_ID=p10 Будет ли достаточно поменять p10 -> 10 только в cpe? Или лучше поменять и VERSION с VERSION_ID. > - Для обычных продуктов убрать минорную версию из СРЕ (10.1, 10.2,... -> 10) > - Для СП8 оставить как есть, т.к. 8.3 и 8.4 это разные продукты. А для СП, который будет на репозитории c10f1, а потом с10f2? Сейчас там так: ALT SP Workstation: NAME="ALT SP Workstation" VERSION="10" ID=altlinux VERSION_ID=10 PRETTY_NAME="ALT SP Workstation 11100-01" ANSI_COLOR="1;33" CPE_NAME="cpe:/o:alt:spworkstation:10" HOME_URL="https://basealt.ru/" и ALT SP Server: NAME="ALT SP Server" VERSION="10" ID=altlinux VERSION_ID=10 PRETTY_NAME="ALT SP Server 11100-01" ANSI_COLOR="1;33" CPE_NAME="cpe:/o:alt:spserver:10" HOME_URL="https://basealt.ru/"
(Ответ для Anton Farygin на комментарий #5) > Но нужно будет пересобирать эти пакеты после бранчевания. Перед выходом первых продуктов на новом бранче, они так или иначе пересоберутся.
> %_priority_distbranch Облом. Он есть в rpm, но отсутствует в rpm-build.
(Ответ для Sergey V Turchin на комментарий #9) > > %_priority_distbranch > Облом. Он есть в rpm, но отсутствует в rpm-build. %define BRANCH $(rpm --eval %_priority_distbranch)
(Ответ для Антон Мидюков на комментарий #10) > %define BRANCH $(rpm --eval %_priority_distbranch) Пейздесь кофе. Ну, придётся. ;-)
@ldv - нам очень нужен бранч в rpm-build. Без извращений.
(In reply to Anton Farygin from comment #12) > @ldv - нам очень нужен бранч в rpm-build. Без извращений. $ hsh-run -- rpm --showrc |grep branch -14: _priority_distbranch sisyphus $ hsh-run -- rpmbuild --showrc |grep branch -14: _priority_distbranch sisyphus
(Ответ для Dmitry V. Levin на комментарий #13) > $ hsh-run -- rpmbuild --showrc |grep branch > -14: _priority_distbranch sisyphus Так, но ошибка: Macro %_priority_distbranch not found на этой же системе. Или без hsh-run это не работает?
(Ответ для Dmitry V. Levin на комментарий #13) > (In reply to Anton Farygin from comment #12) > > @ldv - нам очень нужен бранч в rpm-build. Без извращений. > > $ hsh-run -- rpm --showrc |grep branch > -14: _priority_distbranch sisyphus > $ hsh-run -- rpmbuild --showrc |grep branch > -14: _priority_distbranch sisyphus Как так ? $ rpmbuild --showrc|grep priority_distbranch|wc -l 0 $ rpm --showrc|grep priority_distbranch -14: _priority_distbranch sisyphus В hasher тоже не работает: [builder@localhost .in]$ rpmbuild --showrc|grep priority_distbranch|wc -l 0 $ hsh-run -- rpmbuild --showrc|grep branch|wc -l 0 $ hsh-run -- rpm --showrc|grep branch|wc -l 1
$ hsh-run -- rpmquery -f /usr/lib/rpm/macros.d/altlinux-release altlinux-release-sisyphus-20201124-alt1.noarch Пакет altlinux-release-$branch устанавливается в сборочную среду как при обычной сборке, так и при тестовой пересборке.
(Ответ для Dmitry V. Levin на комментарий #16) > $ hsh-run -- rpmquery -f /usr/lib/rpm/macros.d/altlinux-release > altlinux-release-sisyphus-20201124-alt1.noarch LOL
(Ответ для Dmitry V. Levin на комментарий #13) > > @ldv - нам очень нужен бранч в rpm-build. Без извращений. > $ hsh-run -- rpm --showrc |grep branch > -14: _priority_distbranch sisyphus > $ hsh-run -- rpmbuild --showrc |grep branch > -14: _priority_distbranch sisyphus Без изврата это не работает. https://git.altlinux.org/tasks/312542/gears/200/git?p=git;a=commitdiff;h=8e3fa1e966bf1d0f03d1eb4a6f971dc398ceda08
(Ответ для Sergey V Turchin на комментарий #18) > (Ответ для Dmitry V. Levin на комментарий #13) > > > @ldv - нам очень нужен бранч в rpm-build. Без извращений. > > $ hsh-run -- rpm --showrc |grep branch > > -14: _priority_distbranch sisyphus > > $ hsh-run -- rpmbuild --showrc |grep branch > > -14: _priority_distbranch sisyphus > Без изврата это не работает. > https://git.altlinux.org/tasks/312542/gears/200/git?p=git;a=commitdiff; > h=8e3fa1e966bf1d0f03d1eb4a6f971dc398ceda08 А в сборочнице то работает, так как там приоритет у altlinux-release-$branch при инициализации hasher. На самом деле это же здорово! Если пакет собрали не на сборочнице, то %_priority_distbranch будет текстом. Дополнительная защита от подделки (защита от честных людей и самого себя). В случае брендингов это же очень хорошо.
(Ответ для Антон Мидюков на комментарий #19) > > Без изврата это не работает. > > https://git.altlinux.org/tasks/312542/gears/200/git?p=git;a=commitdiff; > > h=8e3fa1e966bf1d0f03d1eb4a6f971dc398ceda08 > А в сборочнице то работает Ну, ладно. Я себе костыль сделал.
(In reply to Антон Мидюков from comment #19) > А в сборочнице то работает, так как там приоритет у altlinux-release-$branch > при инициализации hasher. В локальном хэшере при установки приоритета для altlinux-release-sisyphus в Сизифе у меня тоже работает. А вот для p10 все равно нет, т.к. в altlinux-release-p10 не задается %_priority_distbranch.
(Ответ для Mikhail Efremov на комментарий #21) > (In reply to Антон Мидюков from comment #19) > > А в сборочнице то работает, так как там приоритет у altlinux-release-$branch > > при инициализации hasher. > > В локальном хэшере при установки приоритета для altlinux-release-sisyphus в > Сизифе у меня тоже работает. А вот для p10 все равно нет, т.к. в > altlinux-release-p10 не задается %_priority_distbranch. Действительно. Нужно исправить altlinux-release-p10.
(Ответ для Антон Мидюков на комментарий #22) > (Ответ для Mikhail Efremov на комментарий #21) > > (In reply to Антон Мидюков from comment #19) > > > А в сборочнице то работает, так как там приоритет у altlinux-release-$branch > > > при инициализации hasher. > > > > В локальном хэшере при установки приоритета для altlinux-release-sisyphus в > > Сизифе у меня тоже работает. А вот для p10 все равно нет, т.к. в > > altlinux-release-p10 не задается %_priority_distbranch. > > Действительно. Нужно исправить altlinux-release-p10. [#318341] p10 EPERM (try 3) altlinux-release-p10.git=20210721-alt2
(Ответ для Антон Мидюков на комментарий #23) > (Ответ для Антон Мидюков на комментарий #22) > > (Ответ для Mikhail Efremov на комментарий #21) > > > (In reply to Антон Мидюков from comment #19) > > > > А в сборочнице то работает, так как там приоритет у altlinux-release-$branch > > > > при инициализации hasher. > > > > > > В локальном хэшере при установки приоритета для altlinux-release-sisyphus в > > > Сизифе у меня тоже работает. А вот для p10 все равно нет, т.к. в > > > altlinux-release-p10 не задается %_priority_distbranch. > > > > Действительно. Нужно исправить altlinux-release-p10. > > [#318341] p10 EPERM (try 3) altlinux-release-p10.git=20210721-alt2 Пришло в p10. Можно использовать.
(In reply to Danil Shein from comment #6) > - Для обычных продуктов убрать минорную версию из СРЕ (10.1, 10.2,... -> 10) Почему? Из спецификации CPE это совсем не следует. Напротив, в примерах именно полная версия, а не ее часть.
(In reply to Anton Farygin from comment #5) > да, мне тоже нравится идея в os-release добавлять произвольное поле > ALT_BRANCH_ID и в него записывать %_priority_distbranch > Только предлагаю это делать через branding пакеты, которые при сборке для > бранча будут к себе записывать куда-то в бинарный пакет %_priority_distbranch Мне не сложно добавить ALT_BRANCH_ID, но хотелось бы понимать, действительно ли это кому-то надо и где и для чего это используется. Также следует учитывать, что это поле будет отражать только тот факт, что в системе скорее всего стоит branding, собранный для указанного бранча и больше ничего. Какие пакеты и откуда еще там установлены, что написано в apt source.list и т.п. - все это так же неизвестно.
Задание с исправленным /etc/os-release в брендинге стартеркитов ушло в p10: [#320276] p10 DONE (try 2) branding-alt-starterkit.git=10-alt3
На данный момент ALT_BRANCH_ID внедрён в os-release следующих брендингов: branding-xalt-kworkstation branding-alt-spserver branding-alt-spworkstation branding-alt-starterkit branding-alt-sisyphus branding-alt-mobile-sisyphus
А что должно быть в NAME написано? Только у kworkstation: NAME="ALT" У других дистрибутивов имя дистрибутива: NAME="Simply Linux" NAME="ALT Education" NAME="ALT Server" NAME="ALT Virtualization" NAME="ALT Mobile" NAME="ALT Mobile Sisyphus" У регулярок: NAME="Sisyphus" У стартеркитов: NAME="starter kit" То есть выбиваются из общей канвы kworkstation, стартеркиты и регулярки.
(Ответ для Антон Мидюков на комментарий #29) > А что должно быть в NAME написано? > Только у kworkstation: > NAME="ALT" Мне другой информации пока не поступало. Может, есть тайное общество именователей, но я в нём не состою. > У других дистрибутивов У меня есть мнение, что это костыли. 2 Shaba: прошу уточнить.
По поводу os-release. Уже слишком много наколхозили все самостоятельно. Но man os-release видимо читали плохо. Я могу высказать только свои пожелания, т.к. не мантейнер пакета alt-os-release. 1) NAME="ALT Linux" для всех 2) PRETTY_NAME индивидуально для разных дистрибутивов 3) VARIANT="Workstation Edition", VARIANT_ID=workstation - индивидуально для разных дистрибутивов.
(Ответ для Alexey Shabalin на комментарий #31) > По поводу os-release. Уже слишком много наколхозили все самостоятельно. Но > man os-release видимо читали плохо. > Я могу высказать только свои пожелания, т.к. не мантейнер пакета > alt-os-release. > 1) NAME="ALT Linux" для всех Значит, никто не угадал, и всем нужно переделать. Все согласны с таким NAME?
(Ответ для Антон Мидюков на комментарий #32) > (Ответ для Alexey Shabalin на комментарий #31) > > 1) NAME="ALT Linux" для всех > Значит, никто не угадал, Я угадал в любом случае, т.к. мой вариант был определён тоже Алексеем. > и всем нужно переделать. > Все согласны с таким NAME? Я не против, но подозреваю, что оно менее универсальное, чем "ALT".
(Ответ для Alexey Shabalin на комментарий #31) > 3) VARIANT="Workstation Edition", VARIANT_ID=workstation Прошу Евгения, как автора изменения в alt-os-release, прояснить Будет ли корректно для Рабочей станции К: VARIANT="Workstation Edition", VARIANT_ID=kworkstation ?
Прошу Евгения, как автора добавления VARIANT и VARIANT_ID в alt-os-release привести примеры для всех дистрибутивов по возможности, чтобы избежать такого бардака, как сейчас.
На текущий момент, видимо, более правильно будет указать так: VARIANT="Workstation K", VARIANT_ID=edition_kworkstation В целом, если редакции не предусмотрены, то эти опции можно не указывать. Редакции необходимы для их использования при отображении компонентов, как перечня сопровождаемой в рамках продукта пакетной базы. Далее можно вчитываться, по желанию. Если ничего не делать, то предполагается определённая обратная совместимость. __________________________ Более развёрнуто для чего это нужно? Для определения текущей редакции и задания другой редакции из доступных. Если в дистрибутиве не предусмотрено несколько редакций, то эта возможность (указание редакции в /etc/os-release и dconf'е /etc/dconf/db/default.d/99-edition) нужна только для определения информации о текущей редакции по умолчанию. Получение информации о текущей редакции, что влияет на список компонентов из которых состоит продукт, как набор компонент, отображаемых в alteratorctl или alt-components. Если редакция не указана, то отображаются все доступные компоненты. Список компонент, входящих в редакцию определяет пакетную базу сопровождаемую в рамках продукта. А перечень пакетов, определяется описанием продукта, как набора компонент: $ alteratorctl editions info edition_domain | head -n20 type = "Edition" name = "edition_domain" display_name.en = "ALT Domain" display_name.ru = "Альт Домен" license = "ALT_Domain_License/11.0" arches = [ "x86_64", "aarch64" ] desktop_environment = "GNOME" kflavours = { default = "6.12", options = [ "6.6", "6.12" ] } languages = { default = "ru", options = [ "ru", "en" ] } [sections.base] display_name.en = "Base components" display_name.ru = "Базовые компоненты" components = [ # system/brandings: "branding-alt-server", # system/boot: "firmware", Все эти описания собираются в рамках пакета alt-components-base: $ rpm -q alt-components-base alt-components-base-0.8.0-alt1.noarch $ rpm -q alt-editions-server --queryformat="%{SOURCERPM}\n" alt-components-base-0.8.0-alt1.src.rpm Опция license определяет каталог с файлами лицензии "/usr/share/distro-licenses/" + license: $ rpm -ql distro-licenses | grep ALT_Domain_License/11.0 /usr/share/distro-licenses/ALT_Domain_License/11.0 /usr/share/distro-licenses/ALT_Domain_License/11.0/distbranch.list /usr/share/distro-licenses/ALT_Domain_License/11.0/license.all.html /usr/share/distro-licenses/ALT_Domain_License/11.0/license.ru.html /usr/share/distro-licenses/ALT_Domain_License/11.0/target.list $ sudo alterator-cmdline /notes action read url:/usr/share/distro-licenses/ALT_Server_License/11.0/license.all.html Текст лицензии и описание редакции могут быть получены напрямую из интерфейса. ________________ Подробнее про интерфейс. Префикс edition_ нужен для того, чтобы избежать потенциального пересечения по именам объектов на шине. Дело в том, что alterator-manager и alterator-module-executor пока ещё не умеют полноценно в дерево. Хотя интерфейсы у объектов разные и конфликт, в общем случае, крайне маловероятен. Предполагается, что VARIANT_ID может быть использован для обращения за информацией о продукте. Методы для интерфейса org.altlinux.alterator.edition1, имя объекта формируется как "/org/altlinux/alterator/" + VARIANT_ID: $ busctl call org.altlinux.alterator /org/altlinux/alterator/edition_domain org.altlinux.alterator.edition1 Description Info License Методы для глобального интерфейса org.altlinux.alterator.current_edition1 позволяют вычислить текущую выбранную редакцию или задать другую, предварительно показав (или не показав) лицензию: $ busctl call org.altlinux.alterator /org/altlinux/alterator/global org.altlinux.alterator.current_edition1 Description Get Info License Set $ busctl call org.altlinux.alterator /org/altlinux/alterator/global org.altlinux.alterator.current_edition1 Get asi 1 "edition_server" 0 Список всех доступных редакций вычисляется по перечню объектов на шине $ alteratorctl manager getobjects --system org.altlinux.alterator.edition1 <<< Объекты на системной шине: /org/altlinux/alterator/edition_domain /org/altlinux/alterator/edition_server ___________________ На уровне необходимых пакетов это выглядит так: $ rpm -ql branding-alt-server-release /etc/altlinux-release /etc/buildreqs/packages/ignore.d/alt-server-release /etc/dconf/db/default.d/99-edition /etc/fedora-release /etc/redhat-release /etc/system-release /usr/lib/os-release $ cat /etc/dconf/db/default.d/99-edition [org/altlinux/product/edition] current='edition_server' $ rpm -qR branding-alt-server-release alt-os-release alt-editions-server rpmlib(PayloadIsLzma) $ rpm -ql alt-editions-server /usr/share/alterator/editions /usr/share/alterator/editions/edition_domain /usr/share/alterator/editions/edition_domain/description.html /usr/share/alterator/editions/edition_domain/description.ru.html /usr/share/alterator/editions/edition_domain/edition_domain.edition /usr/share/alterator/editions/edition_server /usr/share/alterator/editions/edition_server/description.html /usr/share/alterator/editions/edition_server/description.ru.html /usr/share/alterator/editions/edition_server/edition_server.edition Значение VARIANT_ID, по умолчанию, из os-release продублировано в /etc/dconf/db/default.d/99-edition (см. выше). Это важно для отображения в инструментах и динамического переключения между редакциями. Интерфейс для редакции автоматически создаётся во время установки через файл-триггер: $ cat /etc/alterator/backends/autogenerated-edition-edition_domain.backend type = "Backend" module = "executor" name = "edition_domain" interface = "edition1" [methods.Info] execute = "/usr/lib/alterator-backend-edition/edition_helper.py info edition_domain" stdout_bytes = true [methods.Description] execute = "/usr/lib/alterator-backend-edition/edition_helper.py description edition_domain" stdout_bytes = true environment.LC_ALL = {} [methods.License] execute = "/usr/lib/alterator-backend-edition/edition_helper.py license edition_domain" stdout_bytes = true environment.LC_ALL = {} $ grep editions -R /usr/lib/rpm /usr/lib/rpm/10-alterator-backend-edition.filetrigger:if grep -qs '^/usr/share/alterator/editions'; then /usr/lib/rpm/10-alterator-backend-edition.filetrigger: /usr/lib/alterator-backend-edition/generate-editions-backends _______________________ На уровне зависимостей брендинг с /etc/os-release никак не зависит от бекенда и тащит только описание с редакциями и компонентами: $ rpm -qR branding-alt-server-release alt-os-release alt-editions-server rpmlib(PayloadIsLzma) $ rpm -qR alt-editions-server alt-components-base = 0.8.0-alt1 rpmlib(PayloadIsLzma) $ rpm -qR alt-components-base rpmlib(PayloadIsLzma)
(Ответ для Sergey V Turchin на комментарий #33) > (Ответ для Антон Мидюков на комментарий #32) > > (Ответ для Alexey Shabalin на комментарий #31) > > > 1) NAME="ALT Linux" для всех > > Значит, никто не угадал, > Я угадал в любом случае, т.к. мой вариант был определён тоже Алексеем. > > > и всем нужно переделать. > > Все согласны с таким NAME? > Я не против, но подозреваю, что оно менее универсальное, чем "ALT". shaba@ таки за ALT Linux. Я начал свои брендинги исправлять на "ALT Linux".
(Ответ для Антон Мидюков на комментарий #37) > shaba@ таки за ALT Linux. Я начал свои брендинги исправлять на "ALT Linux". Ок, исправлю на "ALT Linux".
(Ответ для Evgeny Sinelnikov на комментарий #36) > VARIANT="Workstation K", VARIANT_ID=edition_kworkstation Предлагаю не маслить масло. VARIANT_ID=kworkstation https://www.freedesktop.org/software/systemd/man/latest/os-release.html#VARIANT_ID=
(Ответ для Антон Мидюков на комментарий #37) > "ALT Linux". Я не против, но никого не смущает, что это будет расходиться с официальным названием? Все начнут называть "ALT Server" как "ALT Linux Server" и "ALT Education" как "ALT Linux Education". Особенно интересно, что при попытке поправить вы будете посланы в место, где система именно так показала.
(Ответ для Антон Мидюков на комментарий #37) > Я начал свои брендинги исправлять на "ALT Linux". Стартеркиты -- понятное дело.
(Ответ для Sergey V Turchin на комментарий #40) > > "ALT Linux". > Я не против Хотя, буду против, пока это не проанализируют в достаточной степени, чтобы официально принять.
Created attachment 18527 [details] os-release-name-check.sh
(Ответ для Sergey V Turchin на комментарий #43) > Создано вложение 18527 [details] [подробности] > os-release-name-check.sh В скрипте логическая ошибка. В этом смысловом ряду должно быть не $NAME, а $PRETTY_NAME.
(Ответ для Антон Мидюков на комментарий #44) > В этом смысловом ряду должно быть не $NAME, а $PRETTY_NAME. Это и есть ошибка. https://www.freedesktop.org/software/systemd/man/latest/os-release.html Если обратите внимание, то там в NAME указано "Fedora", а не "Fedora Project" и не "Fedora Linux".
Другое дело, что в VARIANT тоже не совсем понятно, т.к. в comment#36 Женин вариант совсем не соответствует примеру из документации.
(Ответ для Sergey V Turchin на комментарий #45) > (Ответ для Антон Мидюков на комментарий #44) > > В этом смысловом ряду должно быть не $NAME, а $PRETTY_NAME. > Это и есть ошибка. > https://www.freedesktop.org/software/systemd/man/latest/os-release.html > Если обратите внимание, то там в NAME указано "Fedora", а не "Fedora > Project" и не "Fedora Linux". Я не увидел в документации строку: NAME VARIANT VERSION Откуда скрипт?
(Ответ для Антон Мидюков на комментарий #47) > Я не увидел в документации строку: > NAME Там есть "Fedora" и "fedoraprpject".
(Ответ для Антон Мидюков на комментарий #47) > Откуда скрипт? Из совсем другого сообщения.
(Ответ для Антон Мидюков на комментарий #47) > Я не увидел в документации строку: > NAME VARIANT VERSION Не суть. В kinfocenter, например, по умолчанию показывается NAME VERSION. https://git.altlinux.org/gears/k/kinfocenter.git?p=kinfocenter.git;a=blob_plain;f=alt-use-pretty-name.patch А исходя из этого у нас и BUILD_ID кривой.
Created attachment 18542 [details] умолчательный kinfocenter Вот так непатченый kinfocenter будет показывать сейчас Рабочую станцию K.
Поступила информация, что "ALT Linux не существует". ;-) https://t.me/alt_smokeroom/282969
Created attachment 18939 [details] Предупреждение о левых дополнениях Вот ещё пример использование NAME в системе.
(Ответ для Sergey V Turchin на комментарий #53) > Создано вложение 18939 [details] [подробности] > Предупреждение о левых дополнениях > > Вот ещё пример использование NAME в системе. А они точно NAME смотрят? Правильный способ смотреть ID. А уж текст любой может быть.
(Ответ для Антон Мидюков на комментарий #54) > А они точно NAME смотрят? Другого такого текста у меня в os-release нет.
(Ответ для Антон Мидюков на комментарий #54) > Правильный способ смотреть ID. А уж текст любой может быть. Неправильный, т.к. "любой текст" там будет криво смотреться.
(Ответ для Антон Мидюков на комментарий #54) > А они точно NAME смотрят? Проверил, точно его.
(Ответ для Sergey V Turchin на комментарий #57) > (Ответ для Антон Мидюков на комментарий #54) > > А они точно NAME смотрят? > Проверил, точно его. И как оно себя с брендингом alt-education ведёт? NAME="ALT Education"
(Ответ для Антон Мидюков на комментарий #58) > NAME="ALT Education" Соответственно, на всех скриншотах будет "ALT Education" вместо "ALT"
Думаю, сначала надо определится, как у нас называется ОС. Она одна разных видов или их несколько разных?
(Ответ для Sergey V Turchin на комментарий #60) > Думаю, сначала надо определится, как у нас называется ОС. > Она одна разных видов или их несколько разных? ОС у нас точно одна. ID у неё altlinux. Осталось определиться, как она называется. ALT или ALT Linux. shaba@ предложил называть ALT Linux: https://bugzilla.altlinux.org/show_bug.cgi?id=45743#c31 (Ответ для Sergey V Turchin на комментарий #50) > (Ответ для Антон Мидюков на комментарий #47) > > Я не увидел в документации строку: > > NAME VARIANT VERSION > Не суть. В kinfocenter, например, по умолчанию показывается NAME VERSION. > > https://git.altlinux.org/gears/k/kinfocenter.git?p=kinfocenter.git; > a=blob_plain;f=alt-use-pretty-name.patch > А исходя из этого у нас и BUILD_ID кривой. Что мешает поправить, чтобы показывалось PRETTY_NAME VERSION? NAME - название ОС, PRETTY_NAME - название дистрибутива.
(Ответ для Антон Мидюков на комментарий #61) > ALT или ALT Linux Я с этим согласен. Можно ALT для официальных дистрибутивов, а ALT Linux для остальных сборок. Если только один, то ALT. Осталось, чтоб остальные подтянулись. > Что мешает поправить, чтобы показывалось PRETTY_NAME VERSION? Потому, что наш путь костылей и подпорок мне не нравится и подзадолбал уже за многие годы. Я уже закостылил kinfocenter, но больше не хочется.
А для Simply Linux что предлагается в NAME, тоже ALT? Просто SL же называется именно "Simply Linux", а не "ALT Simply Linux". И NAME вообще не использовать в PRETTY_NAME?
(Ответ для Mikhail Efremov на комментарий #63) > А для Simply Linux что предлагается в NAME, тоже ALT? Просто SL же > называется именно "Simply Linux", а не "ALT Simply Linux". И NAME вообще не > использовать в PRETTY_NAME? NAME ALT Linux PRETTY_NAME Simply Linux
(Ответ для Антон Мидюков на комментарий #64) > NAME ALT Linux > PRETTY_NAME Simply Linux Тогда в BUILD_ID будет ерунда, там сейчас NAME VERSION. Предполагалось, что в NAME все-таки имя дистрибутива (и только), а в PRETTY_NAME уже более подробная строка. В SL сейчас NAME="Simply Linux" PRETTY_NAME="Simply Linux 11.0 (Giuseppe)" И вообще, если приходится патчить программы для отображения нашего os-release, то это скорее заничит, что в os-release что-то не так.
(Ответ для Mikhail Efremov на комментарий #63) > А для Simply Linux что предлагается в NAME, тоже ALT? Просто SL же > называется именно "Simply Linux", а не "ALT Simply Linux". И NAME вообще не > использовать в PRETTY_NAME? NAME="ALT" PRETTY_NAME="Simply Linux NN.N (ABC)" VARIANT="Simply" VARIANT_ID=simply
(Ответ для Mikhail Efremov на комментарий #65) > И вообще, если приходится патчить программы для отображения нашего > os-release, то это скорее заничит, что в os-release что-то не так. И я об этом. :-)
(Ответ для Sergey V Turchin на комментарий #66) > (Ответ для Mikhail Efremov на комментарий #63) > > А для Simply Linux что предлагается в NAME, тоже ALT? Просто SL же > > называется именно "Simply Linux", а не "ALT Simply Linux". И NAME вообще не > > использовать в PRETTY_NAME? > NAME="ALT" > PRETTY_NAME="Simply Linux NN.N (ABC)" > VARIANT="Simply" > VARIANT_ID=simply Тогда уж VARIANT="Simply Linux" и использовать VARIANT VERSION в BUILD_ID при наличии VARIANT. В принципе, можно и так.
(Ответ для Mikhail Efremov на комментарий #68) > использовать VARIANT VERSION в BUILD_ID при наличии VARIANT Да, там одной версии хватит по сути.
> > использовать VARIANT VERSION в BUILD_ID при наличии VARIANT > Да, там одной версии хватит по сути. Разве что, на случай изменения пакета брандинг-release на другой.
(Ответ для Sergey V Turchin на комментарий #70) > > > использовать VARIANT VERSION в BUILD_ID при наличии VARIANT > > Да, там одной версии хватит по сути. > Разве что, на случай изменения пакета брандинг-release на другой. BUILD_ID у нас однозначно должен давать ответ на вопрос, какой брендинг был установлен изначально.
(Ответ для Антон Мидюков на комментарий #71) > (Ответ для Sergey V Turchin на комментарий #70) > > > > использовать VARIANT VERSION в BUILD_ID при наличии VARIANT > > > Да, там одной версии хватит по сути. > > Разве что, на случай изменения пакета брандинг-release на другой. > > BUILD_ID у нас однозначно должен давать ответ на вопрос, какой брендинг был > установлен изначально. Ну да, нужно знать какой дистрибутив был установлен. Нужно еще и файлтриггер в alt-os-release переделать на использование VARIANT. Я сделаю тогда, будет VARIANT VERSION при наличии VARIANT, иначе NAME VERSION как раньше.
(Ответ для Mikhail Efremov на комментарий #72) > (Ответ для Антон Мидюков на комментарий #71) > > (Ответ для Sergey V Turchin на комментарий #70) > > > > > использовать VARIANT VERSION в BUILD_ID при наличии VARIANT > > > > Да, там одной версии хватит по сути. > > > Разве что, на случай изменения пакета брандинг-release на другой. > > > > BUILD_ID у нас однозначно должен давать ответ на вопрос, какой брендинг был > > установлен изначально. > > Ну да, нужно знать какой дистрибутив был установлен. > Нужно еще и файлтриггер в alt-os-release переделать на использование VARIANT. > Я сделаю тогда, будет VARIANT VERSION при наличии VARIANT, иначе NAME > VERSION как раньше. В большинстве брендингов BUILD_ID уже написан изначально, его не приходится генерировать.
(Ответ для Антон Мидюков на комментарий #73) > В большинстве брендингов BUILD_ID уже написан изначально, его не приходится > генерировать. Да, но учесть возможность все равно надо.
А ещё: $ lsb_release -a LSB Version: n/a Distributor ID: ALT Description: ALT Workstation K 11.1 (Nemorosa) Release: 11.1 Codename: Nemorosa