Здравствуйте, saahriktu.

Если Вы располагаете временем, хотел бы обсудить с Вами насущную проблему повсеместного бардака в ОС Linux на примере...

Вот нашёл я красивую и полезную программу (дисковая диаграмма) Duc: https://pingvinus.ru/program/duc
Иду на сайт программы: https://duc.zevv.nl/

Читаю про сборку и инсталляцию...

Install
To build Duc with its default options, run:

$ ./configure
$ make
$ sudo make install

To get the required dependencies on Debian or Ubuntu, run:
$ sudo apt-get install libncursesw5-dev libcairo2-dev libpango1.0-dev build-essential

On RHEL or CentOS systems, you need to do:
$ sudo yum install pango-devel cairo-devel tokyocabinet-devel

Перед сборкой ставлю devel-зависимости: urpmi --auto pango-devel cairo-devel tokyocabinet-devel

Иду на гитхаб и качаю исходники: https://github.com/zevv/duc/archive/1.4.4.tar.gz
Распаковываю в /duc-1.4.4 и захожу в неё: cd /duc-1.4.4

Имею список файлов:

ls
build/     configure.ac  doc/       gentoo/  INSTALL  Makefile.am  src/      todo     valgrind-suppressions
ChangeLog  COPYING       examples/  img/     LICENSE  README.md    test.sh*  TODO.md

По инструкции делаю следующее:

./configure
bash: ./configure: Нет такого файла или каталога

Здесь хочу ещё раз подчеркнуть, что всё делаю по инструкции с официального сайта.

Чтож. Как обычно ищу переписку адептов и профессионалов в этой сфере...
Через братьев по несчастью и десятые руки нахожу: https://unixforum.org/viewtopic.php?t=87963

Цитата:
Если отсутствует configure, собираем его командами bootstrap или autogen.sh. Если нет и таких скриптов, то пробуем
aclocal
autoheader
automake --gnu --add-missing --copy --foreign
autoconf

Проделываем описанное выше и только теперь делаем то, что написано на сайте:
$ ./configure --prefix=/usr
$ make
#Отлавливаем файлы через porg:
$ porg -lp duc "make install"

Получаем 2 файла:

/usr/bin/duc
/usr/share/man/man1/duc.1

Программа собрана и работает. Проверяем...

#Добавляем каталог в индекс:
duc index /var
#И смотрим результат в гуях:
duc gui /var

Перед упаковкой в пакет требуется сжать в xz man-файл, иначе он не будет включен в пакет...

cd /usr/share/man/man1/
xz ./duc.1

Но возвращаясь к теме бардака... Почему авторы программы предлагают сразу перейти к ./configure, минуя шаманскую стадию:

aclocal
autoheader
automake --gnu --add-missing --copy --foreign
autoconf

Вопрос возник потому, что этими "граблями" усеяны все пути к трезвому, адекватному пониманию того, что именно нужно делать в Линукс, чтобы достигнуть желаемый результат. Почему всё именно так?

А. Вы ещё одну ссылку нашли, как эту проблему решить? )) Так вот я и говорю, как это делается у нормальных людей:
1. Зашёл на сайт
2. Получил всю необходимую информацию
3. Выполнил группу действий и поимел результат

В данном случае, как и в большинстве других с Линуксом имеем другую схему:
1. Заходим на сайт
2. Получаем НЕправильную информацию
3. Начинаем всем миром искать концы
4. Потом вылазит бородатый мужик, говорит "айм сорри, сделайте там autoreconf", но изменения в инструкции на сайте сделать не удосуживается. Кусок бороды здесь, кусок бороды там, всё это размазано попытками участников обсуждения решить проблему своими методами. А методов, как выясняется пруд пруди. И вот время прошло... Исписаны километры форумов, назначены новые гуру и... На сайт заходит следующий нуб... Продолжение Вы уже знаете.

Нет системы, нет стандартов и нет общего вектора развития. Даже в элементарном приходится заниматься доделками/переделками. Почему нет каких-то общих алгоритмов сборки программ? Я не имею ввиду толстенный фолиант с мантрами, а 5-6 страниц понятного текста. Открыл, посмотрел какие файлы присутствуют, каких нет. Поводил по стрелкам пальцем и пришёл к выводу: сделать нужно то-то. Но похоже, уписывать в 5-6 страниц - это не юниксвэй? Юниксвэй - это массовка андеграунда? Нет очертаний системы как таковой, всё из каких-то лоскутов и догадок соткано. Дисциплины нет нигде. Отсюда и назначение для штучных устройств: заточили под определённое железо и пока не устарело продали. Время прошло - ещё нарезали. Что это за подход?

На дворе 21 век. И только в Линуксе нужно встать в какую-то неописуемую раскаряку, чтобы установить программу на компьютер. Сегодня не хватило configure, завтра выяснится, что нужен какой-нибудь ниндзя, кумэйк, симэйк или ещё что. Не устанавливается? Ба! Так это у Вас в системе не хватает заголовочных файлов, других пакетов, других средств сборки, других разных фигней. Их нужно из предыдущей версии брать и собирать в этой. При всём уважении - всё вот это, глобально, ну никак нельзя назвать преимуществом. Поясню иначе...

Вот есть микросхема. Сегодня она содержит 500 транзисторов. Через месяц уже 1500, через 10 лет 2 миллиона. А вот родился человек с нулевым представлением о жизни. Человек ростёт, развивается, берёт в руки паяльник и собирает схему, содержащую микросхему, которая внутри себя содержит 2 миллиона транзисторов.

Человек вовсе не обязан вникать в архитектуру всех технологий и наработок. Из поколения в поколение дискретизация мышления естественным образом меняется: первооткрыватель мыслит штуками, продолжатель мыслит коробками из штук, новое поколение обрабатывает информацию контейнерами из коробок, которые содержат штуки. Линукс же предполагает изучение этих "штук" на всех этапах своего развития. Невозможно что-то сделать в Линукс, если заранее не располагать необходимым представлением о штуках из каменного века. Но прогресс то не стоит на месте. Естественная убыль аудитории, непопулярность ввиду планомерного усложнения всей конструкции - вот последствия такого подхода. Хороший конструктор мог бы состоять не из непонятных штук, а из понятных контейнеров. При всём уважении.

Сорри, мне тут доски на дачу подвозили, пришлось отъехать, поучаствовать. )) Ладно, задам последний вопросище, больше не буду Вас мучить (пока). )) А почему бы на каталог, в который распаковали некий исходник не натравить некую "программу-эксперт"? Скормил ей каталог, она сама определила, что требуется для сборки, сопоставила всё это добро с окружением, в котором запущена и предложила вариант сборки: доустановить то-то, выполнить то-то и т.д. Есть ли такие в природе?

Привет, AlexL. А как оно примерно может называться? Хоть одним глазком глянуть...

В ходе поисков параллельно открыл для себя checkinstall. Он даже в официальных репах Магии есть. Мега-прикольная программа. Сразу, в процессе сборки создаёт пакет из исходников. Пакует всю выжимку в RPM без спеков. Надо же, всё это время совсем рядом был ещё более наглый, прямой конкурент.

Оставлю описание checkinstall для кучи: http://ashep.org/2010/sozdanie-paketov- … ckinstall/
А здесь оригинал статьи по проблеме с отсутствующим configure: https://help.ubuntu.ru/wiki/programs_installation

spec-gen:
http://wiki.rosalab.ru/en/index.php/%D0 … d_Programs
https://pkgs.org/download/spec-gen
4 года назад заглохла разработка, что в принципе для Росы обычное явление.

Господа, а как обустроить для себя сборочную из исходников, чтобы ни в чем себе не отказывать?
Цель: скачать любой интересный исходник с гит-хаба и уже не задумываться о средствах сборки и нюансах. Сейчас ставлю вот такую кучу...

Обязательные:
---
gcc
gcc-c++
ninja
make
cmake
automake
autoconf
meson
qtbase5-common-devel (qmake)
vala (компилятор, часто попадался при сборке)

Разное для пакетов:
---
rpm-build (притянет много полезной фигни)
rpm-sign (подписывать пакеты)
porg (в плюшевом, искать файлы после установки)
deps (в плюшевом, ставит BuildRequires из спеков)
checkinstall (собирает файлы в rpm-пакет; вместо make install, удобно)

Понимаю, что для гуру это выглядит неким лоховством, но мне просто гемор не нужен. Может есть смысл что-то добавить?

p.s. Кто подскажет пакетов пачку, тот получит водокачку.

Очень информативно, AlexL.

Ладно, обещания надо выполнять. Сорри, красные закончились.

Вопрос к мейнтейнерам...

Имеется:
---
%pre - этот сценарий выполняется перед установкой пакета в систему
%post - этот сценарий выполняется после установки пакета в систему
%preun - этот сценарий выполняется перед удалением пакета из системы
%postun - этот сценарий выполняется после удаления пакета из системы

Различаем процедуры установки пакета от обновления пакета:
---

%pre и %post
    if [ $1 -eq 1 ]; then действия; fi - первая установка пакета
    if [ $1 -eq 2 ]; then действия; fi - обновление пакета
%preun и %postun
    if [ $1 -eq 1 ]; then действия; fi - обновление пакета
    if [ $1 -eq 0 ]; then действия; fi - деинсталляция пакета

Работаем с сервисом systemd в спеке (без start, ибо не нужен):
---

%pre
    if [ $1 -eq 2 ]; then systemctl disable мой_сервис.service; fi
%post
    systemctl enable мой_сервис.service
%preun
    if [ $1 -eq 0 ]; then systemctl disable мой_сервис.service;  fi
%postun
    if [ $1 -eq 0 ]; then systemctl daemon-reload; fi

Результат - всё работает: сервис ставится, врубается, при обновлении пакета предварительно отрубается, затем опять врубается, делается рефрэш всех сервисов, а при удалении пакета вырубается и удаляется.

Однако, вот здесь: https://docs.fedoraproject.org/en-US/pa … s/#_syntax в разделе "Scriptlets" написано:

BuildRequires: systemd-rpm-macros
[...]
%post
%systemd_post apache-httpd.service

%preun
%systemd_preun apache-httpd.service

%postun
%systemd_postun_with_restart apache-httpd.service

Дальше можно найти ещё много разных штук из той же оперы: %systemd_post, %systemd_preun, %systemd_postun_with_restart, %systemd_user_post, %systemd_user_preun и т.д.

Вопрос:
---
Что это за лабудень (%systemd_бла_бла_бла)? Если это дополнительные костыли для работы с юнитами systemd в спеках, то где про них можно почитать? Или это какая-то абстрактная фигня, чтобы народ из спеков до пенсии не вылазил?