Ubuntu 23.04

Вау, вот это глубина познаний линукса.

всей внутренней кухней занимается libalpm, а закачкой пакетов и зависимостями pacman

libalpm зависит от cURL:

alpm.c
24:#ifdef HAVE_LIBCURL
25:#include <curl/curl.h>
73:#ifdef HAVE_LIBCURL
74:     curl_global_init(CURL_GLOBAL_ALL);
75:     myhandle->curlm = curl_multi_init();
114:#ifdef HAVE_LIBCURL
115:    curl_multi_cleanup(myhandle->curlm);
116:    curl_global_cleanup();
137:#ifdef HAVE_LIBCURL

Я уже писал, dpkg как отдельная сущность не нужен. Надо или было его сделать полноценным(переписать), либо сделать библиотекой для apt, а сейчас мы имеем именно костыль, и это иначе не назвать

В исходниках там все перемешано, libalpm и pacman в одном архиве. Но я не отрицаю, что libalpm тоже может заниматься закачкой пакетов без pacman

У apt своя база, у dpkg своя. Какой смысл их объединять? Чтобы что?

а уж сколько всякого на Python-биндингах к libapt понаписано…

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

Я уже писал, dpkg как отдельная сущность не нужен. Надо или было его сделать полноценным(переписать), либо сделать библиотекой для apt

Тебе что в лоб, что по лбу - все едино. Вроде тебе уже даже разжевали, что у них (apt и dpkg) разные задачи, но ты все равно тянешь свою несуразицу.

Сдается мне, что ты тоже не в состоянии воспринимать что либо в письменном виде. Помнитцо в дореволюционной России для подобного типа личностей, при обучении, применялся прекрасный инструмент для вливания знаний. Он представлял собой некие такие части кустарника, кои, при приложении с силой к 5-й точке обучаемого, на доступном ему языке доводили до разума нужные знания :)

В исходниках там все перемешано, libalpm и pacman в одном архиве

А в архиве что?

pacman в src, libalpm в lib/libalpm.

Чтобы избавится от костылей. Сейчас в дебиане пакетный менеджер (apt) поверх пакетного менеджера(dpkg). Зачем нужно два пакетных менеджера в одной системе?

И наслаждаться всеми килобайтами этого говна.

…в которых основной объём занимает changelog. Ужас, да.

А сам rules в любом случае максимально нечитабельный. Потому что выбрать в качестве языка билдов язык еще более убогий и эзотерический, чем sh, это ж надо было…

То ли дело shell — он намного лучше! Язык без типизации, без адекватной обработки ошибок (command || true, ага), с кучей подводных камней (забыл кавычки? фигурные скобки? x$var = xy? set -u? pipefail? subshell-ы в pipe-ах? съедающий ошибки declare? exit, который не выходит?)…

Спорить не буду

Билды здорового человека:

https://github.com/void-linux/void-packages/blob/master/srcpkgs/audacious/template

https://gitweb.gentoo.org/repo/gentoo.git/tree/media-sound/audacious/audacious-4.3.ebuild

https://git.alpinelinux.org/aports/tree/community/audacious/APKBUILD

https://git.altlinux.org/gears/a/audacious.git?p=audacious.git;a=blob;f=audacious.spec;h=2da34dd9b8f739bc36e9bc12e5833602291b7fd6;hb=26c41171d4181d0aef3959c0322dce0bf3636376

Один, мать его, файл. Один файл в максимально понятном формате с максимумом информации по делу.

Только в «лучшем линуксе всех времён» уже 30 лет не могут сделать по-человечески…

проще систему превратить в слаку

А в слаке то всё хорошо с пакетированием. А если взять salix, то и вообще прекрасно. Иначе бы они такими малыми силами не потянули дистры с релизами. Так что разводить слаку в слаке мне никогда не приходилось, а в дебиане да, это обычное дело.

То ли дело shell — он намного лучше! Язык без типизации, без адекватной обработки ошибок (command || true, ага), с кучей подводных камней (забыл кавычки? фигурные скобки? x$var = xy? set -u? pipefail? subshell-ы в pipe-ах? съедающий ошибки declare? exit, который не выходит?)…

А make от всех этих проблем избавлен, ага. Жги еще.

Именно!

Зачем нужен пакетный менеджер поверх пакетного менеджера? Пользователю нафиг не сдался dpkg, так что же он тогда делает в bin? Место ему если не в /lib, то в /lib/libexec

Что то говно, что это.

Ты все-же я смотрю зависим от времени года и цветения растений. Тебе уже объяснили, повторяю еще раз. Apt - средство работы с репами и расчета зависимостей, dpkg - средство ЛОКАЛЬНОЙ установки пакетов.

Тебе уже объяснили, повторяю еще раз. Apt - средство работы с репами и расчета зависимостей, dpkg - средство ЛОКАЛЬНОЙ установки пакетов.

В такой формулировке, dpkg - это лишняя сущность, которую надо заменить на tar.

А с чего это установка пакетов разбита для пользователя на две разные прокраммы? Это если всякие dpkg-query не вспоминать. В пакетном менеджере здорового человека должно быть скорее так:

apt install coolprog
apt install --file anothercoolprog.deb

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

Как минимум отсутствие кучи мелких утилит, как в apt.

xbps, кстати, тут ничем не лучше:

xbps-alternatives
xbps-checkvers
xbps-create
xbps-dgraph
xbps-digest
xbps-fbulk
xbps-fetch
xbps-install
xbps-pkgdb
xbps-query
xbps-reconfigure
xbps-remove
xbps-rindex
xbps-uchroot
xbps-uhelper
xbps-uunshare

Что за дистр?

Войд

В такой формулировке, dpkg - это лишняя сущность, которую надо заменить на tar.

О господа! Внимание! Свеженькая бредятинка. Такого еще не встречал. Перепутать пакет и архив для записи на ленту может только истинный рачевод.

Собственно - это все, что нам надо знать о данном товарисче :)

И дико этим бесит. Развели зоопарк имён.

Я бы наоборот даже в Арче часть задач, которые вынесены во внешние утилиты, запихал бы в pacman тоже.

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

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

То есть нет, не задвинешь, как всегда покричишь громко и свалишь в кусты. Эксперт.

Щас ты конечно задвинешь телегу о том, чем пакет отличается от архива,

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

Это просто северный пушной зверь, господа. Тут не поможет даже приложение отростков растений к 5й точке, ибо некуда вливать знания.

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

Нет, до тебя.

запихал бы в pacman тоже

Сложно, нужны спецы Си. :)

Да не, можно сделать костыль - перенести нужные утилиты в libexec, а в код pacman добавить аргументы командной строки для доступа к ним. Получившееся чудо обернуть в пакет, заменяющий пакет pacman. PROFIT!!!!

Как мне с нуля выстроить юзерский реп для деба?

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

Куда мне дальше двигаться, чтобы по итогу получить реп, из которого люди могут ставить ПО? Есть пошаговый мануал?

перенести нужные утилиты в libexec

Её не пишут в Арче, что замечательно.

Получившееся чудо

-юдо никому не нужно.

Это то понятно, но почему бы и нет? Just for fun же.

Как мне с нуля выстроить юзерский реп для деба?

https://vmblog.ru/sozdat-localniy-deb-repo/

С тебя, походу, пора уже деньги брать за разъяснение банальных вещей :)

недостаточно распаковать из архива файлы для установки достаточно многого ПО в систему

Ну и что мешает апту сделать всё необходимое включая распаковку? Только «исторические причины». Сам по себе dpkg абсолютно неюзабельная фигня с точки зрения юзера. С другой стороны, тому же юзеру не очевидно почему это апт не работает с локальным пакетом. Вы просто привыкли к такому изврату, и уже не замечаете насколько это всё упорото. Хорошо хоть от бредового разделения на apt-get/apt-cache ушли (но не везде, привет альту).

Сам по себе dpkg абсолютно неюзабельная фигня с точки зрения юзера. С другой стороны, тому же юзеру не очевидно почему это апт не работает с локальным пакетом.

Я хотел сначала написать, что это понятно любому, даже альтернативно одаренному, но потом вспомнил, что тут у нас есть ты и еще двое на w….

Хорошо хоть от бредового разделения на apt-get/apt-cache ушли (но не везде, привет альту).

Ну может оттого, что Альт, это не дебиан?

Потому что интерфейс пакетного менеджера дебиана устарел и требует полной переработки. Всякие apt-cache выпилить полностью, а dpkg надо вообще убрать и поместить внутрь apt, в каталоге /bin ему точно делать нечего. Вариант, как должна выглядеть установка пакета из файла я привёл.

Потому что интерфейс пакетного менеджера дебиана устарел и требует полной переработки.

Зачем трогать то, что прекрасно работает и так? Походу дела есть только три маргинала, которых это не устраивает. Запилите свое (хотя не осилите даже сборку) и там изголяйтесь сколько хотите. Зачем в свои бредовые идеи других тащить?

Прекрасно работает это сильно… Вот допустим юзер. Скачал себе какую-нибудь программу в виде deb пакета. Открывает man apt, чтобы узнать, как установить локальный пакет. С удивлением обнаруживает, что там этого нет. Идет в гугл, и там узнаёт, что это делает dpkg. И что ему остаётся подумать, кроме как «какой дебил это слелал?»?

А своё мне делать незачем, есть арч, где все сделано по-нормальному.

Куда мне дальше двигаться, чтобы по итогу получить реп, из которого люди могут ставить ПО?

1. Опакетить ваши консольные приложения. Как они собираются?

2. Создать репозиторий:

   • https://www.aptly.info/tutorial/repo/
   • https://manpages.debian.org/bullseye/aptly/aptly.1.en.html

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

3. Опубликовать репозиторий, подписав его вашим ключом.

Если вы всерьёз интересуетесь, без клоунады, то могу помочь, чем смогу.

Сам по себе dpkg абсолютно неюзабельная фигня с точки зрения юзера.

О чём юзера честно предупреждают:

dpkg low level package management system for Debian (file based)

Advanced Packaging Tool (APT).

тому же юзеру не очевидно почему это апт не работает с локальным пакетом.

Работает. «Если ничто другое не помогает, прочтите, наконец, инструкцию!».

Опакетить ваши консольные приложения. Как они собираются?

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

Работает

Не работает без бубна.

dpkg надо вообще убрать и поместить внутрь apt

Ага, а ещё надо убрать сетевой стек и делать всё в одном мега-модуле, ведь разделение уровней не нужно.

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

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

Разделение уровней будет в модулях исходного кода. На уровне бинарников оно тут зачем? Чтобы что?

Надо просто нормальный интерфейс для apt сделать, а что за утилиты оно там будет вызывать, дело десятое. К этому идут, только очень медленно. Уже почти нормально, и 30 лет не прошло.

EndeavourOS uses a rolling release schedule.

Попытайся еще.

Никто не запрещает сделать релизный дистрибутив с pacman, но почему-то никто ещё это не сделал. Возможно по причине ненужности релизов и преймуществах роллинга. Но технических ограничений нет.