Комментарии 23
сегодня 25 августа - день первого упоминания о системе, получившей название Linux, так что 🖐Linux, с днем Рождения!!! 🎂 📖
Не ошибается тот, кто ничего не делает
Поэтому чем меньше задействовано людей и изобретено этапов - тем лучше.
Самый правильный способ - скачать с сайта разработчика. Вариант 1 - скачивается само ПО один раз, а дальше оно обслуживает себя само, как Flutter. Вариант 2 - скачивается скрипт который сам разбирается в идиотизмах Линукс, ставит ПО и дальше оно обслуживает себя само, как Rust. Видно, что этот подход становится основным поскольку на него переходят с альтернатив, как Julia.
Разработчик может не держать ПО у себя, а положить куда положено. Ход мысли приведший к термину «альтернативный менеджер пакетов» мне непонятен - ящичек в шахматном столике не альтернатива загону при хранении коней. Куда положено - это Pip, Cargo и так далее. В принципе - это то же самое что и сайт разработчика, по жизни - может занять вашу драгоценную машину богомерзкой компиляцией.
Разработчик может сам сделать пакет одного или нескольких форматов, Микрософт любит делать DEB. Если менеджер пакетов работает идеально, то у такого подхода есть шанс.
Вместо одного из форматов пакетов разработчик может использовать FlatPak и прочие извращения типа контейнеров. Ожидаемый по жизни результат - система загажена контейнерами и средствами их интеграции в систему, ничего не работает. Да, на каких-то машинах занятых строго ограниченной деятельностью у каких-то разработчиков поддерживаемых отделом техподдержки - безусловно работает, нам то с того?
Можно заниматься конвертацией пакетов, но компилировать самому проще. А если душа согласна компилировать, то есть Gentoo и там возможно всё.
Софт может быть в штатном менеджере пакетов, но не факт что он собран корректно, есть случаи когда мейнтейнерам дистрибутива совершенно невозможно объяснить нетривиальные вещи просто потому что они не тривиальные, и есть примеры урезания функциональности по неведомым причинам, как в .Net.
Само понятие «поиск и установка программ» сколь безграмотно, столь и вредоносно. Нету никаких «программ» которые бы были объединены способами установки. Есть системный софт который много лучше ставить из менеджера пакетов дистрибутива, и есть софт прикладной который лучше ставить непосредственно от разработчика. Соответственно, любой общий алгоритм - чушь и надувательство.
Есть интересные пограничные случаи типа Python. Но это другая история. И есть Arch как пример алгоритма по жизни - из core и multilib ставь, из extra поразмысли и ставь, из AUR хорошенько поразмысли прежде чем ставить.
Конспирология
Если бы я хотел дискредитировать Линукс среди уже подошедших к нему, то заказывал бы такие статьи.
Как назвать по вашему блок с "Pip, Cargo и так далее"?
В остальном не вижу противоречий - написали тоже самое что и в статье, но со своими примерами.
Самый правильный вариант не всегда работает. Даже на крупных сайтах не всегда есть какие-либо удобные форматы использования, или же есть только устаревшие проблемные варианты. Разработчик может не разбираться в тонкостях конкретного linux, а их много. У него может просто отсутствовать мотивация поддерживать все это - чего уж говорить, таким страдают даже техногиганты с миллиардными бюджетами.
Так что правильнее, если пакеты под конкретный дистрибутив все же будет компилировать и собирать тот, кто работает с конкретным дистрибутивом.
На практике лучший опыт получается с софтом, исходники которого публично доступны в каком-нибудь репозитории, без регистрации и смс. Для такого софта доступен самый большой набор вариантов: от собственноручной сборки под свою ОС и машину, до прозрачного встраивания софта в любую пакетную базу: любой заинтересованный человек со стороны может подключить чужой публичный репозиторий к своей системе сборки пакетов, без какой-либо бюрократии и ограничений.
Такой софт доступен практически во всех пакетных базах, даже самых экзотических, и в каждой собирается по-своему: где-то статически, где-то под конкретные системные библиотеки доступные в конкретном релизе дистрбутива.
Абсолютно верно сказано.
С готовыми пакетами есть две стороны 1) разработчики дистрибутива и 2) разработчики ПО и тут либо:
пакет собирают первые (разработчики дистрибутива) и тогда он идеально встроен в дистрибутив (доступны нужные версии библиотек-зависимостей), будет ярлык в кнопке Пуск, настройки по умолчанию, контекстные менюшки в файловом менеджере и остальное принятые в этом дистрибутиве плюшки. НО делает это человек знающий дистрибутив, а не разработчик ПО (то есть может поверхностно знать внутренности самого ПО, тем более нюансы новой версии ПО при её выходе).
пакет собирают вторые (разработчики ПО) и тогда они идеально знают своё ПО, но не знают 100500 особенностей различных дистрибутивов и пакет будет "так себе" встроен в систему (чем проще утилита, тем меньше проблем).
У пакетов с открытыми исходниками меньше проблем с внедрением в различные системы (дистрибутивы), так как он проходит через глаза разных ментейнеров (разработчики разных дистрибутивов) и их работа по внедрению в систему накапливается (появляются spec-файлы для сборки пакета, документация, локализация на разные языки и тд) - эти наработки часто используется для сборки этого пакета в 100500ый новый дистрибутив. С закрытым ПО (даже если есть пакет под Linux) нет таких возможностей.
Просто у меня всё время ощущение, что среднестатистический пользователь считает, что "разработчик должен сделать пакет для установки ПО" и не задумывается, что под словом "разработчик" две обычно не связанных между собой стороны (разработчики дистрибутива и разработчики ПО). Пользователю конечно и не нужно в этом разбираться, но все ошибки ожидания (должен ли быть пакет в репозитории, насколько он должен быть интегрирован в систему и т.д.) из этого проистекают.
Самый правильный вариант не всегда работает.
Всё не всегда раюотает, достаточно того, что работает на порядок чаще.
Разработчик может не разбираться в тонкостях конкретного linux, а их много
Это не разработчик, это криворукая обезьяна которая пишет по принципу "Мама, смотри - заработало". Не нужны разработчику тонкости дистрибутива, ему нужно чтобы работали конкретные вещи. Если разработчик не знает какие - обезьяна. Если не может проверить работает ли - тоже, или того хуже - нейросеть. И что это так было очевидно в здоровое время, см. autoconf.
Разработчик ПО не знает тонкостей дистрибутива, не потому что криворук, а потому что дистрибутив очень много и помимо сделанных по одним лекалам (различные ...-based дистрибутивы) есть очень уж много таких что авторы продвигают какой-то новый подход (как то всякие "атомарно обновляемые", "свой формат пакетов", "все прикладное в snap" и 100500 других идей, о которых я даже пока не догадываюсь хотя видел много разных дистрибутивов).
Ну и изучайте, что значит заклинание:
./configure && make && sudo make install
"make install" - скверный совет для дистров на базе deb и rpm
Сборка пакетов deb, rpm без установки.
sudo checkinstall --install=no
https://pkgs.org/download/checkinstall
https://en.wikipedia.org/wiki/CheckInstall
https://checkinstall.izto.org/
Конвертация пакетов
https://en.wikipedia.org/wiki/Alien_(file_converter)
Alien is a program that converts between the rpm, dpkg, stampede slp, and slackware tgz file formats
Alien (apk, deb, rpm, txz)
https://pkgs.org/download/alien
Спасибо, ссылки добавлю
Определить, с каким дистрибутивом совместим, используемый вами дистрибутив, можно командой: grep ID_LIKE /etc/os-release
Универсальный способ:
cat /etc/*release* и cat /proc/versionЕще варианты: hostnamectl, lsb_release -a, uname -a
Только эти (hostnamectl, lsb_release -a, uname -a, cat /etc/*release* и cat /proc/version)
показывают "какой дистрибутив используете",
а не "с каким совместим используемый вами дистрибутив"
Все просто работает:
cat /etc/*release && cat /etc/debian_version
for i in $(ls /etc/*release); do echo ===$i===; cat $i; done
проще и корректнее (без проблем с файлам в названии, которых есть "пробел"):
tail -n+1 /etc/*release
Да, годный вариант
Поля ID_LIKE в /etc/os-release на Alt Linux, Fedora и ROSA FRESH нет.
Номинально есть в РЕД ОС. В AlmaLinux, Rocky Linux, Oracle Linux и OpenSUSE лень проверять.
С rpm-base не сложилось, только по необходимости(объекты КИИ). Arch и Debian - любимые дистры
:)
Посмотрел из своих старых записей - три дистрибутива:
NAME="Rocky Linux"
VERSION="9.3 (Blue Onyx)"
ID="rocky"
ID_LIKE="rhel centos fedora"
...
NAME="SLES"
VERSION="15-SP5"
VERSION_ID="15.5"
PRETTY_NAME="SUSE Linux Enterprise Server 15 SP5"
ID="sles"
ID_LIKE="suse"
...
NAME="Manjaro Linux"
PRETTY_NAME="Manjaro Linux"
ID=manjaro
ID_LIKE=arch
...
NAME="MOS Desktop"
ID=mos
ID_LIKE=rosa
PRETTY_NAME="MOS Desktop 12"
...
В M OS от ДИТ МСК умудрились сломать anaconda installer. Нет настройки сети "Имя сети и узла"
Для всех пользователей (без телеметрии без техподдержки ДИТ)
MOS_2021.1_MOS-V_x86_64_240724.iso
https://abf.mos.ru/product_build_lists
https://hub.mos.ru/mos/iso/-/packages/33
https://abf.mos.ru/platforms/rosa2021.1/products/1/product_build_lists/80
Не упомянули "distro agnostic" статически скомпилированные бинарники опер-сурсных программ, которые есть в, например, GitHub releases. Их нет в репозиториях пакетных менеджеров, а собирать - накладно.
Для таких штучек есть простейший пакетный менеджер eget, который установит бинари в /usr/bin или куда вам нужнее.
От меня небольшой пiдарочек:
Плейбук для установки eget
---
- name: Ensure eget is installed and updated
hosts: all
become: true
vars_files:
- "{{ inventory_dir }}/vars/vars.yaml"
vars:
project_dir: eget
dest_project_fullpath: "/home/{{ standard_user }}/{{ project_dir }}"
tasks:
- name: Check if eget is already installed
command: which eget
register: eget_installed
ignore_errors: true
- name: Download eget installation script
get_url:
url: https://zyedidia.github.io/eget.sh
dest: /tmp/eget.sh
mode: '0755'
when: eget_installed.rc != 0
- name: Run eget.sh to install eget
shell: "bash /tmp/eget.sh"
when: eget_installed.rc != 0
- name: Run eget to update itself
command: eget zyedidia/eget
when: eget_installed.rc == 0
- name: Move eget binary to /usr/local/bin
command: mv ./eget /usr/local/bin/
args:
creates: /usr/local/bin/eget
- name: Remove eget.sh
file:
path: /tmp/eget.sh
state: absent
- name: Remove eget binary file in user directory
file:
path: "{{ dest_project_fullpath }}"
state: absent
Плейбук для установки пакетов с помощью eget
---
- name: Ensure eget is installed and updated
hosts: all
become: true
vars_files:
- "{{ inventory_dir }}/vars/vars.yaml"
tasks:
- name: Check if eget is already installed
command: which eget
register: eget_installed
ignore_errors: true
- name: Download tstack/lnav
command: 'eget tstack/lnav --asset lnav --to /usr/local/bin'
when: eget_installed.rc == 0
ignore_errors: true
- name: Download koenbollen/jl
command: 'eget koenbollen/jl --to /usr/local/bin'
when: eget_installed.rc == 0
ignore_errors: true
- name: Download mikefarah/yq
command: 'eget mikefarah/yq --asset yq_linux_amd64 --to /usr/local/bin'
when: eget_installed.rc == 0
ignore_errors: trueeget - интересная идея (есть риск не проверенные вредонос запустить, но мысль интересная). Переварю - добавлю в статью
А из упомянутых в ansible-плейбуке: утилитой yq пользовался, lnav не давно как раз натыкался (с мыслей, что вроде интереснее чем ccze) - и yq и lnav встречал в репозиториях некоторых дистрибутивах
tstack/lnav - The Logfile Navigator
koenbollen/jl -- translating structured message into old-fashioned log lines
mikefarah/yq -- lightweight and portable command-line YAML, JSON and XML processor
Добавил в пункт Архив с исполняемыми файлами:
eget (📨) - утилита для скачивания ПО в виде небольших предварительно скомпилированных утилит из GitHub. Оно ищет в, указанном в виде аргумента команды, github-репозиторие исполняемый файл (в том числе и внутри архивов, а также переименует appimage-файл) и копирует его в /usr/local/bin
Альтернативные способы поиска и установки программ в Linux