Ubuntu 23.04

Этот что ли?

https://aur.archlinux.org/packages/tonelib-gfx-bin

А что так можно было?

В этом вашем ауре даже цитрикс обнаружился, в таком же формате. Полезно.

Именно так и происходит, когда оформить сборку пакета занимает 10 минут копипаста по образцу из другого пакета, и сборочный скрипт не содержит ни одной лишней непонятной строчки.

А не как в сабже.

Так ты скоро на Windows 11 перейдешь, латентный виндузятник.

Слушай, ну ты бы матчасть подучил, а? В репах кроме последнего стабильного релиза есть еще lts и rt. В ауре валяется еще стопицот разных версий.

Еще нашел rt версии 5.15

И как это поможет от перезаписи файлов ядра при обновлении?

Так что решение всё равно плохое, пусть в репозитории другие ядра и есть.

при перезаписи у тебя есть другая версия ядра. Загружаешься с этой версией и переустанавливаешь/откатываешь из кеша пакет с основной версией.

при перезаписи у тебя есть другая версия ядра. Загружаешься с этой версией и переустанавливаешь/откатываешь из кеша пакет с основной версией.

Это да, но я и не про это. Я согласен, что наличие других веток ядра в репозитории позволяет решить возможную проблему незагружаемости системы с новым ядром (правда, для этого эту другую ветку нужно предварительно самому поставить).

Однако с перезаписью нового ядра поверх старого есть и другие проблемы. Система фактически превращается в тыкву до перезагрузки: подключил новое устройство, требующее загрузку модуля — не заработает, поскольку модулей от текущей версии ядра уже на диске нет, а от новой они не загрузятся из-за несовпадающих версий. Большинство дистрибутивов, сохраняющих предыдущие версии ядра, при удалении этих ядер имеет проверку, не позволяющую удалить текущее загруженное ядро — ровно по этой причине.

Ну поставил ядро и перезагрузился. В чем проблема?

А мне-то ты это зачем пишешь? Про одно ядро арчедрочер утверждал, а не я.

– Вы обновляете убунтов?

– Нет, сижу на LTS

– Ненужное…

Ненужновое :)

Самый главный вопрос во всём этом бардаке:

Мне как разработчику что в систему контроля версий ложить?

В любой нормальной системе пакетирования я кладу туда рецепты сборки. Хоть в Alpine, хоть в Gentoo, не важно.

Для дебиана мне как поддерживать историю версий сборочных рецептов, если по кокнутой логике дебиана они лежат ВНУТРИ сорцов апстрима?

Я вот сколько раз пытался взяться за то, чтобы поддерживать сборку пакетов для дебиана, и каждый раз я представляю себе этот хаос и посылаю всё это нахрен. Это, сцуко, больно. Я не хочу.

До какого звиздеца нужно довести систему, если на вопрос «как мне собрать пакеты», самый частый ответ - это: «херачь checkinstall-ом».

Меня вон просят софт под убунту опакетить. Я отказался. Я не мазохист. Или не настолько мазохист.

Для дебиана мне как поддерживать историю версий сборочных рецептов, если по кокнутой логике дебиана они лежат ВНУТРИ сорцов апстрима?

Они там лежат, только если разработчик программы их туда положил. В терминологии Debian это native Debian package.

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

Они там лежат, только если разработчик программы их туда положил.

Они там лежат по логике работы процедуры сборки пакетов.

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

А на практике это хранится вот так: https://github.com/mati75/openbox-debian

Я «могу» их хранить «как удобнее», только на практике никто этого способа не знает. Это как в том анекдоте, который Путин рассказывал.

Может это просто я 15 лет не вкупаю, в чем тут соль? Адекватный процесс сборки софта прост как мычание и выглядит так:

• Скачиваем архив сорцов у апстрима.
• Распаковываем.
• Накладываем патчи, если требуется.
• Компилим, если софт компилируемый.
• Устанавливаем во временный DESTDIR.
• Добавляем метаинформацию о пакете.
• Архивируем в пакет.

Все эти действия машина выполняет автоматически согласно написанному рецепту.

В Дебиане - ????

Я вот сколько раз пытался взяться за то, чтобы поддерживать сборку пакетов для дебиана, и каждый раз я представляю себе этот хаос и посылаю всё это нахрен. Это, сцуко, больно. Я не хочу.

Не хотите – не делайте. Задолбали ныть уже.

Я вам минимально необходимое для сборки дал? – дал. Это заняло 100500 строк кода? – нет, не заняло. Но у вас постоянно куча заявлений в воздух о том, каквсёсложна!11, но нет никакой чёткой конкретной информации о том, что именно у вас не получается.

Короче, или давайте по существу, или заканчиваем. Мне надоело взагали по загалям болтать.

что именно

Для начала, у меня не получается понять workflow, в котором мне не нужно будет танцевать вприсядку с машиной, чтобы опакетировать 15 сорцов.

Все маны на эту срань начинаются так: «скачайте архив сорцов программы и переименуйте его в *_orig.*». Такое ощущение, что в мире дебиана компьютеры еще не изобрели.

Вот пример, как это делается для Арча: https://github.com/sde-gui/pacman.sde-git

Запускаем make, через 3-10 минут все пакеты собраны и установлены локально.