Ubuntu 23.04

Для справки, размер бинарной сборки pacman:

$ pacman -Qql pacman | grep '[^/]$' | grep '/usr/\(bin\|lib\)'| grep -v 'makepkg' | tr '\n' '\0' | du -h --files0-from=- --apparent-size
143K	/usr/bin/pacman
38K	/usr/bin/pacman-conf
6,7K	/usr/bin/pacman-db-upgrade
22K	/usr/bin/pacman-key
19K	/usr/bin/repo-add
8	/usr/bin/repo-elephant
8	/usr/bin/repo-remove
14K	/usr/bin/testpkg
14K	/usr/bin/vercmp
13	/usr/lib/libalpm.so
17	/usr/lib/libalpm.so.13
242K	/usr/lib/libalpm.so.13.0.2
311	/usr/lib/pkgconfig/libalpm.pc

Это объем двоичного кода, в котором содержится полностью функциональный пакетный менеджер, со всеми фичами. Со сравнительной таблицей фич можно ознакомиться тут: https://wiki.archlinux.org/title/Pacman/Rosetta

Это инструмент, решающий задачу. Его задача - практическая. А не надрачивание на число бинарников в сборке.

Открывает man apt, чтобы узнать, как установить локальный пакет. С удивлением обнаруживает, что там этого нет.

Там есть недокументированная фича в apt-get. Но я бы не стал этим пользоваться, мало ли чего. А dpkg прекрасен тем, что не решает зависимости. Короче, дебиан не для слабаков.

Есть препятсвия. Сделай с пакманом ту же убунту. Ну чтобы 20.04, 22.04, 22.10 и 23.04 одновременно в одном архиве. Уже много раз говорилось, что сделать из убунты арч можно, а вот из арча убунту никак.

Надо просто нормальный интерфейс для apt сделать, а что за утилиты оно там будет вызывать, дело десятое.

Discover в KDE уже написан, а что за утилиты оно там вызывает, дело не десяти юзеров.

Всмысле в одном архиве. Если честно, то не понял

Это наверное про http://archive.ubuntu.com/

По ссылке я вижу зеркало репозиториев убунты, и смысл становится ещё менее понятным

Хотя не, я вообще не могу понять, что это.

Это не зеркало. Это и есть единый реп убунты.

Допустим, но тогда я не могу понять смысл сообщения про архивы

Да то и значит, что в одном репозитории пакеты для кучи веток. Кстати, оказывается до 31 мая ещё 18.04 поддерживается.

Ну и? Пакеты лежат в общем пуле, а конкретная операционная система пакеты ставит в соответствии с конкретной базой данных пакетов дистрибутива.

Ничего не мешает то же самое делать для пакмана.

Собираются как обычно: ./configure опции && make && make install.

Ну тогда для начала прописываете себе в окружение:

DEBEMAIL="email@example.org"
DEBFULLNAME="Имя Фамилия"

Далее создаёте в каталоге проекта:

1. debian/control – метаинформация о проекте и пакетах:

Source: <имя вашего проекта>
Maintainer: Имя Фамилия <email@example.com>
Section: misc
Build-Depends:
 debhelper-compat (= <версия debhelper, которую вы используете>),
 <остальные зависимости сборки>

Package: <имя двоичного пакета>
Architecture: any
Depends:
 ${shlibs:Depends},
 ${misc:Depends},
 <остальные зависимости>
Description: <краткое описание пакета>
 <полное>
 <описание>
 .
 <пакета>

2. debian/changelog – история изменений:

   Данный файл управляется с помощью утилиты dch из состава пакета devscripts, которая сама форматирует содержимое согласно стандарту.

   Например, для создания нового файла: dch --create --package <имя проекта> -v <версия проекта>.

   Схема работы: вы документируете изменения в пакете, вызывая dch, и затем финализируете их с помощью dch -r. Версии увеличиваются или автоматически, или можете указать свою через -v ....

   Подробности: man dch.

3. Простейший debian/rules – правила сборки пакетов:

#!/usr/bin/make -f

%:
	dh $@

4. debian/copyright – тут очевидно.

как будто бы анаконда лучше… одно время очень глючила.

Cinnamon
От куда качать?

https://www.linuxmint.com/download.php

если минт, то я лучше xfce выберу

Jvm-ы отлично уживаются друг с другом, джавасофт отлично пакуется в фатджарки штатными средствами («почти стандартными» плагинами к популярным системам сборки)

Ну есть ещё Calamares.

Ты уж определись

А у тебя экспериментирование с системой подразумевает бессмысленный труд? Ах ну да, ты же виндузятник.

Кстати, мне nala нравится. Вдруг кому захочется попробовать :-)

Любопытно, не слышал про такое - мерси за совет: действительно захотелось :)

Нафига это дробление на стопятсот утилит?

Я админю зоопарк машин с линем и виндой

Виндузятнику не нравится как организован юникс. Беда-беда, что же теперь делать?! :-D :-D :-D

Я админю зоопарк машин с линем и виндой

Я это не писал, ты что-то перепутал.

Виндузятнику не нравится как организован юникс

Наоборот, мне всё нравится. Претензий к coreutils и им подобным у меня вообще нет. А вот apt действительно сделан через задницу. Зачем ОДНОЙ программе иметь множество бинарников в системе? Пакетный менеджер решает одну задачу - установка програмного обеспечения. Если пакетный менеджер начинает думать за пользователя(например эти ваши update-alternatives), то это уже больше одной задачи. Что не UNIX-way. А дробление одной программы на 100500 бинарников это дикость, от которой надо избавлятся.(Те же coreutils, там же нет grep-stdin, grep-file; все делает одна утилита)

Ах ну да, ты же виндузятник.

Виндузятнику не нравится как организован юникс. Беда-беда, что же теперь делать?! :-D :-D :-D

Если не секрет, ты школу хотя бы окончил?

Ну, прямо скажем, пакман, хоть и приятен своим минимализмом, но предполагает изрядного профессионала за штурвалом.

Года три назад, в предыдущий подход к Арчу, я получал и развалы локально собранных пакетов от того, что пакеты с системными .so-шками проапдейтились. Сейчас, вроде, такого уже не добиться, но о зависимостях на версию .so-шки с определенным интерфейсом по-прежнему «нет, не слышали». Плюс, омерзительная привычка большого числа контрибьюторов АУРа писать пкгбилды в расчёте на сборку не в минимальном чруте… Начинаешь собирать пакет в чруте - и бах!, - билдзависимостей не хватает.

Претензий к coreutils и им подобным у меня вообще нет.

А с чего это копирование, перемещение, удаление, сжатие, сравнение файлов разбиты для пользователя на разные прокраммы? Это если всякие mc не вспоминать. В файловой утилите здорового человека должно быть скорее так:

file -c file1 file2
file -m file1 file2
file -r file1
file -z file1

Нафига это дробление на стопятсот утилит?

Мы ранее использовали reprepro, но aptly вроде как удобнее.

Я бы сразу в https://build.opensuse.org/ закинул и не парился.

А в виде отдельной программы он не нужен.

То есть сначал ты долго доказывал что update-alternatives не нужен, а потом когда понял что облажался - срочно решил изобрести какой-нибудь недостаток дебьяна, которого нет в арче?

До чего же ламеры предсказуемы всё-таки.

Ага, надо было apt-get-update, apt-get-install и т.д. отдельными утилитами для пущей юниксвейности. Ну и apt, aptitude и synaptic сжечь как виндузячью ересь. Кстати, сам факт наличия стольких несовместимых утилит уже намекает, что с пакетной системой не всё хорошо.

Ага, надо было apt-get-update, apt-get-install и т.д. отдельными утилитами для пущей юниксвейности.

В мандриве так и сделали:

urpmi установить
urpme удалить
urpmi.update обновить индекс
urpmf запрос по файлу
urpmq запрос к БД
...

В epm пошли дальше, сделали и нашим и вашим:

epm -i (package), epm install (package) или epmi (package)
epm -i (package file), epm install (package file) или epmi (package file)
epm -e (package), epm remove (package) или epme (package)
epm -s (text), epm search (text) или epms (text)
epm -q (package), epm installed (package) или epmq (package)
epm -qa, epm packages или epm list или epmqa
epm -qp <word>, epmqp
epm -qf (file), epmqf (file)
epm -sf <file>, epm filesearch
epm -ql (package), epm filelist <package>
epm -qi (package), epm info (package)
...

Никто пока не жаловался, до этого момента.

update-alternatives на самом деле не нужен. Пакетный менеджер пытается что-то делать за пользователя. Хотя его работа - это закинуть нужные файлы в нужные места. Остальное его касаться не должно. Зачем менять DM пользователю при его установке или удалении? Если ему надо, сам переключит. А если не надо, то тем более нефиг решать за пользователя.

Ну описанные проблемы это вообще не проблемы пакмана, криво собранные AUR пакеты к пакетному менеджеру не относятся. Пакетный менеджер выполняет свою работу - установка софта. Что там внутри его не волнует.

Зависимости на определённую версию есть, просто в ауре этим не особо пользуются

Остальное его касаться не должно.

О чём я и говорю - сломанная загрузка как результат удаления пакета в арче пакетного менеджера не касается: убогая недоделка этот ваш рач.

Ещё раз, медленнее: пакетный менеджер не отслеживал все необходимые зависимости на версии .so-шек, позволяя апгрейдить пакеты с библиотеками, и не предлагая удалить пакет, зависящий от .so-шки.

Впрочем, сейчас это уже починили.

При чем здесь аур?

Кажется, Вы просто не представляете себе предмет обсуждения.

Со времен возникновения Федоры релиз у нее был пол года из-за Гнома, хотя Вы и так это знаете.

Просто раньше Федора объявляла заморозку, и Убунта быстрее Федоры, все надергов с нее, выкатывала релиз перед Федорой.

Что ты подразумеваешь под сломанной загрузкой? Если удалить ядро или повредить initramfs, то да, загрузка сломается. Если будет хрень в fstab тоже (но это уже не к арчу, а к systemd). А при отсутствии DM ты просто увидишь консольное предложение ввести логин и пароль.

Я не понял, это баг pacman или просто в пакете не бвли прописаны версии библиотек?

Ага, надо было apt-get-update, apt-get-install и т.д. отдельными утилитами для пущей юниксвейности.

Так много где, между прочим. Взять тот же опёнок.

Но вот вы мне скажите, в чём принципиальная разница при гипотетическом наборе:

apt<дефис>install

– вместо

apt<пробел>install

?

Кстати, сам факт наличия стольких несовместимых утилит уже намекает, что с пакетной системой не всё хорошо.

С чего это вдруг они несовместимые? Можно использовать хоть все сразу.

А вообще, интересно выходит у пользователей Arch:

• С одной стороны, мы гордимся и всюду рассказываем, какой же классный у нас AUR.
• С другой стороны, критикуем apt за наличие разных утилит управления пакетами.
• А потом ставим пакеты из стандартных репозиториев через pacman, а из AUR – через yay, paru или чем там сейчас модно пользоваться.

К сожалению, твой уровень знаний не позволяет нам продолжить дискуссию. Извини. Приходи лет через 15 =)

в чём принципиальная разница при гипотетическом наборе

Не знаю, надо дебианщиков спросить зачем им понадобился apt и почему все радостно его используют вместо связки утилит. Может быть не слишком прикольно каждый раз вспоминать в каком именно бинарнике реализована нужная команда. Там же нет такого, что 1 утилита = 1 команда, это хоть было бы логично.

С чего это вдруг они несовместимые? Можно использовать хоть все сразу.

У aptitude своя решалка зависимостей и своя база метаданных. Какая уж тут совместимость, они друг о друге вообще не знают. Использовать можно на свой страх и риск. Про синаптик не знаю, это какое-то ненужно для мышевозов. Не удивлюсь, если им тоже можно что-нибудь сломать.

интересно выходит у пользователей Arch

Это не ко мне.

Какая уж тут совместимость, они друг о друге вообще не знают. Использовать можно на свой страх и риск. Про синаптик не знаю, это какое-то ненужно для мышевозов. Не удивлюсь, если им тоже можно что-нибудь сломать.

Ты это прям сейчас придумал как и то, что apt не умеет ставить локальные пакеты?

Благодарю. Пока не было времени заняться, на днях попробую.

Ну это уже не к пакетному менеджеру вопрос, а к правилам пакетирования.

То, что зависимости не указывают точную версию so, был бы недостаток для сервера. А для домашней машины это скорее упрощение. Некоторая разболтанность в управлении зависимостями имеется, конечно.

В случае, если в апстриме so обновилась на несовместимую версию, обычно можно из AUR поставить предыдущую рядом, и всё продолжит работать.

В общем, за 10 лет, я никаких практических проблем с этим не обнаружил.

Когда apt мозги парит, предлагая удалить полсистемы для разрешения зависимостей, это ничем не лучше.

Кстати, вот сейчас пользуясь убунтой в виртуалке, я вдруг понял, что в этой системе как и 10-15 лет назад, мне проще открыть санаптик и кликать там мышкой, чем вспоминать и учить команды пакетного менеджера.

Ни в одной другой ОС у меня таких практических проблем с командами не было. А в Арче вообще никогда не возникает необходимости иметь графическую морду для управления пакетами, настолько там всё просто и очевидно в терминале. Хотя какие-то морды есть, но я их даже не ставил никогда.

Признаю, я слишком тупой для апта.

Но вот вы мне скажите, в чём принципиальная разница при гипотетическом наборе

https://wiki.archlinux.org/title/Pacman/Rosetta

Разница на практике очевидна.

А потом ставим пакеты из стандартных репозиториев через pacman, а из AUR – через yay, paru или чем там сейчас модно пользоваться.

Хрен знает, я до сих пор через устаревший yaourt ставлю.

У aptitude своя решалка зависимостей

Да.

и своя база метаданных.

Нет. Своя у неё лишь база свойств, специфичных для самой aptitude, типа «Unseen».

Какая уж тут совместимость, они друг о друге вообще не знают.

Им друг о друге знать и не надо. Достаточно того, что они используют libapt, которая решает общие для них задачи.

Это не ко мне.

А вы чем пользуетесь?

В принципе согласен, но у пакмана тоже есть один недостаток - нужно запомнить ключи. А дальше удобно, вместо многословного install просто -S. Единственное, что не сильно удобно искать пакеты в пакмане нужные, хотя можно использовать что то типа pacman -Ssi запрос

Какая разница, какой фронтенд для AUR. Интерфейс у всех одинаковый и копирует pacman. Ну кроме pamac, но это поделие манджары не нужно

Я не знаю, как им это удалось, но мне вообще не пришлось специально запоминать ключи. Сами очень быстро выучились.

Ну как-то мой мозг проще запоминает pacman -Rscn, чем apt autoremove --purge.