Любительская разработка в debian и не только.

[ferum]

1) Мотивация
Думаю что все давно заметили какими темпами в 21 веке меняется жизнь, что уж говорить о мире компьютеров и программного обеспечения
новые проекты появляются как грибы в лесу после тёплого дождя. Наш любимый дистрибутив с завидным постоянством выпускает стабильный релиз приблизительно каждые два года, в современных условиях это срок, существует даже расхожее мнение что debian уже при выходе имеет несколько "протухший" софт. Чтож ни куда не денешься за свободу и стабильность надо чем то платить. Вместе с тем практически все мы хотим пользоваться всеми последними достижениями и благами цивилизации да и вроде бы ни что особо не мешает, разве что собственная лень...
В  последние годы молодые программисты очень много всего выкладывают в виде исходных кодов в открытый доступ, больше того, они охотно ведут диалог с разработчиками и конечными пользователями своих программ на предмет исправления ошибок и совершенствования своих продуктов.
Таким образом у каждого пользователя есть потенциальная возможность не только решить свои вопросы но и поучаствовать, в меру сил конечно, в развитии нашего дистрибутива.

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

2) Осмотримся в системе.
Наш debian с момента установки собирается из пакетов как здание из кирпичиков, но что же находится в этих пакетах? Как устроено их содержимое? Как они находят свои места в системе? Что бы ответить себе на эти вопросы давайте сначала рассмотрим систему поверхностно, не влезая в подробности, просто как некое хранилище файлов.
По скольку человеку свойственно воспринимать окружающее как картинку посмотрим на файлы через любой имеющийся графический файловый менеджер nautilus dolphin thunar или любой другой установленный в вашей системе. Домашний каталог пользователя сейчас нас не интересует по этому через настройку режима просмотра выставляем показывать скрытые файлы и переходим в файловую систему. С правами обычного пользователя мы ни чего не сломаем но можем посмотреть какие каталоги, подкаталоги и файлы мы имеем в файловой системе. Подойдёт для этой цели и mc а ещё лучше krusader эти файловые менеджеры наглядно показывают древовидную форму нашей файловой системы. Правда без прав суперпользователя нам не откроется каталог /root но нам там пока нечего делать. Забегая вперёд скажу что больше всего нас будут интересовать пути
/usr  /usr/bin  /usr/local /usr/sbin /usr/lib
/etc /etc/init /etc/init.d /etc/default
/etc/apt здесь хранится информация об источниках ПО.
в несколько меньшей степени /var /var/lib
/var/cache/apt/archives — где хранятся копии установленных пакетов.
/opt

Даже после беглого знакомства заметно что в /../../bin и в /.../...sbin находятся приимущественно двоичные исполняемые файлы но могут присутствовать и исполняемые командные сценарии для оболочки
в /usr/share  лежат компоненты наших приложений в том числе шаблоны конфигурационных файлов и даже темы и иконки для наших приложений
/etc занят приимущественно конфигурационными файлами и стартовыми скриптами.
В /.../lib находятся так называемые библиотеки -базы данных из которых если так можно выразиться исполняемые алгоритмы получают информацию для своей работы.
Всё достаточно сложно и степень глубины познаний скорее всего должна быть обусловлена поставленой задачей. Досконально знать всё очень сложно. Тем не менее мы должны для себя уяснить что между  этими файлами существует взаимная связь и работать один без другого они не будут, больше того они ищут друг друга в строго определённых местах и места эти могут быть определены третьим, четвёртым и пятым файлами.

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

3) Готовый deb пакет содержимое
Продолжим практику визуального изучения файловой системы но уже на примере готового пакета. Для примера возьмём хотя бы пакет gedit простейший текстовый редактор среды gnome (ну может быть не простейший).
Для этого поступим очень просто
создадим себе любую папку в домашнем каталоге
например tmp так как папка временная и потом мы её просто удалим.
mkdir -p tmp
cd tmp
находясь в этой папке скачаем пакет с помощью aptitude
sudo aptitude update
aptitude download gedit
Это не обязательно должен быть gedit, можете скачать любой интересующий вас пакет но у меня получился gedit_3.4.2-1_amd64.deb
Вскроем его и посмотрим что находится у него внутри.
Выполняем команды в терминале и поглядываем через файловый менеджер что у нас происходит в папке tmp
ar vx gedit_3.4.2-1_amd64.deb
Наблюдаем появление двух архивов control.tar.gz  data.tar.gz   и файла debian-binary который текстовый и пока не содержит для нас полезной информации
Вскрываем далее
tar -xzvf data.tar.gz
tar -xzvf control.tar.gz
Обратили внимание что после распаковки архива data у нас появилась папка /usr со всеми подпапками и файлами, забегая вперёд скажу , примерно те же файлы появились бы у вас в системе после установки gedit из исходных текстов  а вот то что образовалось при распаковке архива control результат работы сборщика пакета. Это файл control который даёт менеджеру управления пакетами информацию о зависимостях и конфликтах а так же об архитектуре пакета, три служебных сценария для корректной автоматической установки/удаления пакета ну и текстовый файлик md5sums сгенерированный утилитой dpkg  при сборке пакета
На самом деле работа сборщика значительно больше, просто  большая часть её пошла на то что бы представить пользователю пакет уже в готовом виде.
Напоследок удалим все файлы что распаковали кроме нашего пакета gedit и рядом с ним создадим папку например ge она будет имитировать нашу корневую файловую систему
и выполним распаковку пакета с помощью dpkg
dpkg-deb -x gedit_3.4.2-1_amd64.deb /home/user/tmp/ge
Обратите внимание ни один из служебных файлов не остался в нашей файловой системе.
Можете проделать подобную процедуру с разными пакетами, в том числе скачивая их по зависимостям, и если распаковывать их поочерёдно можно смоделировать полную установку программы но думаю и так понятно что готовый deb пакет представляет собой специальный архив дополненный служебной информацией для работы менеджера пакетов и это ценно.
Хотя по идее скомпилированные файлы можно вручную раскидать по папкам, дать соответствующие права и если все необходимые компоненты найдут своё место программа будет работать. Вместе с тем надо понимать что если пакет/архив сделан неправильно или по правилам другого дистрибутива результатом его установки может быть не только нарушение работы менеджера управления пакетами но и неработоспособность системы.

4) Пакет исходного кода debian
Его необходимо рассмотреть для дальнейшего понимания процесса.
Установим в систему (если ещё не установлен) пакет dpkg-dev, естественно по зависимостям он приведёт в систему ещё много чего но если вы предполагаете попробовать свои силы в разработке все эти пакеты вам потребуются, если не потребуются всё легко удаляется командой
apt-get purge dpkg-dev && apt-get autoremove
Снова возвращаемся в нашу папку /tmp (лучше предварительно её очистить) Добавляем  или раскоментируем в sources.list
deb-src http://ftp.ru.debian.org/debian wheezy main contrib non-free (У меня старый стабильный дистрибутив на этом компьютере, что не меняет суть дела). Обновляем сведения об источниках и скачиваем пакет с исходным кодом того же gedit. Кстати название пакета исходного кода в большинстве случаев может отличаться от названия бинарного пакета но тут уже https://packages.debian.org/search?suite=default&section=all&arch=any&searchon=sourcenames&keywords=gedit  гугловский поисковик в помощь

apt-get source gedit
получаем gedit_3.4.2-1.debian.tar.gz  gedit_3.4.2-1.dsc gedit_3.4.2.orig.tar.xz и папку gedit-3.4.2 в которую собственно у нас автоматически и распаковался архив с исходниками.
Если бы мы скачали эти три файла через браузер или с помощью wget для распаковки нам бы пришлось выполнить
dpkg-source -x gedit_3.4.2-1.dsc
Идём в папку gedit-3.4.2 , естественно наибольший интерес для нас представляет дебианизация, изучаем папку /debian
Сразу видим что наш сопровождающий внёс изменения по отправке информации об ошибках (присутствует патч) , прописал информацию о сборочных и установочных зависимостях, так же мы видим что из пакета исходного кода получаются несколько бинарных пакетов gedit  gedit-common gedit-dev в текстовых файлах ...install  прописаны конкретные пути куда будут скопированы файлы полученные в результате компиляции исходников и этот порядок определён именно для данного дистрибутива, скажем в ubuntu он может несколько отличаться хотя бы потому что там другая версия gnome. changelog  мы подробнее рассмотрим когда дойдём до сборки пакетов. Особого  внимания конечно заслуживает скрипт rules . Он очень индивидуален для сборки каждого пакета исходного кода как раз тот случай когда возможно долго и нудно придётся разбираться с официальным талмутом разработчика и описанием сборки конкретной программы. К счастью многие программы собираются по простому обращению rules к другим скриптам autogen.sh или configure а при бэкпортировании практически всегда можно стянуть шаблон из старых исходников, иногда обходится даже без изменений или находится ответ на " ошибку которую в случае своей невалидности rules обязательно выдаст.
По мимо имеющихся в данном архиве файлов в подкаталог debian часто включаются готовые конфигурационные файлы  и стартовые скрипты, место нахождения которых после установки бинарного пакета определяется файлами ...install на стадии составления пакета исходного кода.

5) Нет не страшно
Риск испортить систему ничтожно мал если использовать правильные инструменты. Все наверное слышали о виртуальных машинах в которых можно творить что угодно а потом просто удалить целиком но нам потребуется не VMware и не Virtualbox нам для компиляции потребуется чистая среда, то есть минимальная система, в которую мы поставим инструменты разработки и сборочные зависимости и только по мере необходимости.
Такая среда может быть установлена даже для сборки пакетов другой архитектуры и другого дистрибутива , например предыдущего или следующего релиза debian , любого ubuntu а при желании и других дистрибутивов linux но мы пока остановимся на debian.

6) Чистая среда для сборки
Возможно кто то знает больше но я нашёл для себя два прекрасных варианта сборочных машин. Это стандартные программы из репозитория debian устанавливаются совершенно нормальным способом через любой менеджер приложений.

1) pbuilder удобно использовать с небольшой надстройкой cowbuilder, в связке с debootstrap это мощное средство, позволяющее устанавливать большое количество виртуальных сборочных систем, их максимальное количество ограничено размерами корневой файловой системы или каталога /var если при разметке он был вынесен отдельно. Перед установкой виртуальных машин требуется настроить cowbuilder
sudo nano /etc/pbuilderrc

Код Выделить Развернуть


BUILDPLACE=/var/cache/pbuilder/build/
        USEPROC=yes
        USEDEVPTS=yes
        USEDEVFS=no
        BUILDRESULT=/var/cache/pbuilder/result/
        #у меня кэширующий apt-cacher, пожтому я отключил кэширование пакетов внутри pbu
        ilder
        #APTCACHE="/var/cache/pbuilder/aptcache/"
        APTCACHE=""
        REMOVEPACKAGES=""
        HOOKDIR=""
        export DEBIAN_FRONTEND="noninteractive"
        DEBEMAIL="Alexander GQ Gerasiov < gq@cs.msu.su >"
        BUILDSOURCEROOTCMD="fakeroot"
        PBUILDERROOTCMD="sudo"
        DEBBUILDOPTS=""
        APTCONFDIR=""
        BUILDUSERID=1000
        BUILDUSERNAME=gq
        export LOGNAME=gq
        BINDMOUNTS=""
        unset DEBOOTSTRAPOPTS
        export PATH="/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin"
        export SHELL=/bin/bash
        DEBOOTSTRAP="cdebootstrap"
        PKGNAME_LOGFILE_EXTENTION="_$(dpkg --print-architecture).build"



При установке виртуальная машина сворачивается в образ, экономя дисковое пространство  ( и прячась от посторонних глаз) а при запуске разворачивается во вполне реальную примонтированную операционную систему.
Пример установки архитектуры идентичной хосту
sudo debootstrap jessie /var/cache/pbuilder/base.jessie
Если установка 32 битной виртуалки производится на 64 битный хост (с добавленной поддержкой мультиарч)
sudo debootstrap --variant=buildd --arch=i386 jessie /var/cache/pbuilder/i386.jessie
в случае установки сторонней либо устаревшей операционной системы о которой на текущий момент в скриптах debootstrap недостаточно информации в команде может быть точно указан адрес источника пример:
sudo debootstrap --variant=buildd --arch=i386 vivid /var/cache/pbuilder/ubuntu.i386  http://archive.ubuntu.com/ubuntu/

При первом после установки запуске доступ к такой виртуалке доступен только через команду chroot.
sudo chroot /var/cache/pbuilder/base.jessie
После установки в виртуалку средств разработки и редактирования в ней sources.list выход по команде exit и следующий вход
sudo cowbuilder --login --save-after-login --basepath /var/cache/pbuilder/base.jessie
Далее создаём каталог где будем заниматься сборкой
mkdir -p build
переходим в него, создаём по мере необходимости субдирректории удобным способом через wget  или  mc  с правами суперпользователя затаскиваем в среду исходники и приступает к работе.
Из хоста через mc с правами суперпользователя ( лучше sudo ) запущенная в pbuilder машина видна по пути
/var/cache/pbuilder/build/cow**** там видно дерево каталогов установленной машины и каталоги для сборки которые мы создали
по пути /var/cache/pbuilder/base.jessie находится образ машины, когда она запущена так же наблюдается дерево каталогов...но только наблюдается.
Возможно я что то не так делаю но вопреки утверждениям http://www.opennet.ru/base/sys/debian_backport.txt.html  оригинал статьи прекратил существование в папку result  ни чего не попадает, всё приходится доставать через mc.
Это обстоятельство и задержку по времени на разворачивание и сворачивание образа машины при включении выключении  можно отнести к  основным недостаткам pbuilder.

2) schroot вторая программа для установки чистой сборочной среды.Также как и pbuilder её удобно использовать в тандеме с debootstrap  . Настройка  приложения требует создания в корневой файловой системе хоста дополнительного каталога.
sudo apt-get install schroot debootstrap
sudo nano /etc/schroot/chroot.d/debian.i386.conf

Код Выделить Развернуть


debian_i386]
description=Debian Jessie 32-Bit
personality=linux32
directory=/srv/chroot/debian_i386
root-users=your_username
type=directory
users=your_username

your_username имя любого пользователя зарегистрированного на данном хосте и имеющего домашнюю папку, после установки и настройки виртуальной сборочной системы ему даже необязательно обладать правами sudo.
sudo mkdir -p /srv/chroot/debian_i386
Установка самой машины
sudo debootstrap  jessie /srv/chroot/debian_i386
так же как и в случае с pbuilder на 64 битный хост с мультиарч можно поставить 32 битную виртуалку.
sudo debootstrap --variant=buildd —arch=i386 jessie /srv/chroot/debian_i386
Настройка источников
sudo nano /srv/chroot/debian_i386/etc/apt/sources.list
Настройка чистой среды schroot закончена, можно логиниться простому пользователю, тому кто прописан в  /etc/schroot/chroot.d для данной отдельно взятой машины, я на своих хостах единственный пользователь со всеми правами в противном случае прежде чем залогиниться в виртуалке пользователю лучше создать папку где будет производится сборка например  build в случае если она будет создана из виртуалки прав на эту папку без sudo у пользователя уже не будет.
Логинимся в виртуалку , ни каких дополнительных прав для этого не нужно.
schroot -c debian_i386 -u root
При этом остаёмся в собственном домашнем каталоге но уже типа рутом debian_i386 которая у нас виртуальная но вполне реальная. Переходим в каталог build, ставим необходимые нам средства разработки начиная с
apt-get update
apt-get install build-essential
качаем исходники, творим что хотим. Выход из виртуальной среды schroot  такой же как и из cowbuilder  просто exit.
В итоге не знаю плюс это или минус гостевые системы не сворачиваются в образ, логин в виртуалку мнгновенный. Исходники удобно помещать в папку  где производим сборку, удобно так же забирать результат и выбрасывать строительный мусор. Все файлы исходников просматриваются в графическом режиме ( чего не скажешь о pbuilder где mc верх удобства). Дисковое пространство корня не тратится на размещение исходников.
Из минусов заметен отдельный каталог в корне хостовой системы +необходимость создавать конфигурационные файлы в /etc/schroot/chroot.d для каждой системы.
За наличием дискового пространства следить приходится однозначно, вывод прост предполагаешь заниматься разработкой не жалей места под корень. Для переустановки виртуальной debian ( приведения в исходное состояние) достаточно повторно использовать debootstrap.

Небольшое уточнение по поводу  debootstrap этот пакет мультиархитектурный содержит одни скрипты и не имеет сложных зависимостей то есть я могу скачать его например из https://packages.debian.org/sid/debootstrap  и установить вручную даже в squeese это даёт возможность содавать виртуальные машины последних современных дистрибутивов даже на old old stable что собственно говоря я и практикую как вариант.

7) Схема поиска необходимого софта достаточно проста. Поисковик находит варианты программ для решения какой либо задачи, а сейчас очень многие приложения разрабатываются как мультиплатформенные. Вероятность того что мы обнаружим программу которая поддерживается в линукс даже несколько выше чем например для OSX (MacOS). Тем не менее если программа имеет специфическое назначение (аудиторию) или появилась недавно вовсе не факт что она уже имеется в официальных источниках нашего любимого дистрибутива. Вообще есть достаточно достойных проектов которые категорически не интересны нашим сопровождающим, скорее всего у последних просто не хватает ресурсов сил и времени. Таким образом мы можем получить программное обеспечение только в виде исходного кода.

Источники.
У значительной части проектов имеются официальные сайты на которых можно скачать стабильные версии продуктов дополнительно приведены ссылки на
http://sourceforge.net/ или https://github.com/ на этих ресурсах сейчас расположилось множество девелоперских проектов их численность постоянно растёт а состав обновляется.
Есть проекты остающиеся актуальными на протяжении существования нескольких поколений дистрибутивов коды из которых могут быть собраны например как на старом стабильном дистрибутиве так и в тестируемом, естественно иногда уже требуется наложение специальных патчей. К таким источникам можно отнести https://www.mercurial-scm.org/wiki/Repository и https://pikacode.com/
Естественно в работе этих проектов задействованы одни и те же люди занимающиеся разработкой свободного программного обеспечения по этому между источниками существует  вполне просматривающаяся связь а в дистрибутивах давно существуют стандартные инструменты для удобного получения кода из таких источников. Те кто имеет некоторый опыт жизни в linux скорее всего успели заметить что в официальные источники попадают только определённые версии программ , возможно они лучшие но в принципе можно получить доступ практически к любой версии программы.
Для удобства существуют https://ru.wikipedia.org/wiki/Subversion  https://ru.wikipedia.org/wiki/Mercurial
Таким образом для того что бы комфортно загрузить найденные исходники нам могут понадобиться.
1) wget с ним всё ясно
wget адрес ссылки на архив
2) git  для загрузки незаавхивированной дирректории с исходникоми с соответствущего ресурса.
           git clone адрес найденой ссылки
3) mercurial  для загрузки незаавхивированной дирректории с исходникоми с mercurial или picacode ( возможно и других источников)
            hg clone адрес найденой ссылки
4) subversion для загрузки  незаавхивированной дирректории с исходникоми с репозиториев использующих систему управления версиями.
svn co адрес найденой ссылки
Загрузка исходников с помощью систем контроля версий требует наличия этих систем, установленных в компьютере (git, svn, mercurial), если при загрузке исходников была использована одна из таких систем, её принято указывать в /debian/control как сборочную зависимость хотя бы потому что в некоторых случаях целесообразно готовить скрипт /debian/rules таким образом чтобы при пересборке пакета из deb-src исходники автоматически заменялись на последнюю версию из интернета. Естественно написание такого скрипта требует достаточно высокой квалификации, тем не менее занимаются этим совсем не боги.
    Существуют ситуации когда необходима простая пересборка пакета находящегося в родном репозитории debian , для этого у нас в sources.list должен быть прописан сорцовый репозиторий deb-src мы уже разбирали как получить пакет с исходным кодом.
В моей личной практике на wheezy был случай когда изменение всего одной сборочной зависимости повлекло необходимое мне изменение характеристик приложения.
Дело в том что в linux некоторые пакеты могут заменять друг друга а при смене компонентов конечное приложение может вести себя несколько другим образом.
Речь в частности идёт о медиаплеере для KDE kaffeine .Начиная по крайней мере с debian lenny и по wheezy включительно в качестве движка   использовался xinelib  версии 1.1 который использовал для декодирования видео исключительно центральный процессор что делало совершенно невозможным просмотр  видео высокого качества в этом медиаплеере при наличии слабого процессора, последний загружался на 100%  и появлялись артефакты звука и видео. Вместе с тем если видеокарта поддерживает аппаратное ускорение и использовать хотя бы mplayer с включённым аппаратным видео нагрузка на процессор ничтожна. Естественно ещё в KDE 3.5 делались удачные попытки пересобрать kaffeine что бы использовать xinelib1.2 в качестве движка. Ни о каких пакетах тогда конечно речи не было
собирали всё исключительно из свежайших на тот момент исходников.
Используя wheezy я решился на эксперимент когда просто напросто в стандартном пакете исходного кода  kaffeine сделал изменения в /debian/control  в сборочных и установочных зависимостях изменил libxine1-* на libxine2-* Пакет успешно собрался в чистой среде, после чего я убрал из системы libxine1-* добавил libxine2-* и установил собственный пакет. Пересобранное приложение прекрасно заработало.
Решение пришлось по вкусу многим любителям спутникового тв, использующим kaffeine.
Удивительно но уже в debian jessie ( через пару лет ) сопровождающий пришёл точно к такому же решению, возможно просто потому что xinelib1.1 попросту выбросили из репозитория как устаревший.
Чисто технически в качестве источников исходного кода могут быть использованы и  сорцовые репозитории  ubuntu как впрочем   и других базирующихся на debian дистрибутивах если в них находится интересующяя нас программа. Другой вопрос что нельзя использовать такой код без анализа и соответствующих изменений ( иногда можно но всё равно надо тщательно всё проверять).
Рассмотрим конкретный пример использования таких источников.

Пересборка пакета или бэкпортирование
Термин пересборка  не совсем правильный для бинарного пакета debian ведь имеющийся бинарный пакет разбирать не приходится. На практике делаются необходимые изменения в пакете исходного кода (deb-src) это может быть наложение дополнительных патчей, изменение сборочных и установочных зависимостей, как на примере с kaffeine, изменение конфигурационных файлов и стартовых скриптов, обычно такие изменения связаны с портированием приложения из одного дистрибутива в другой. Сборку пакетов с такими изменениями принято называть бэкпортом.
Многие пользователи использующие wine для запуска игр и некоторых windows приложений столкнулись с проблемой что wine1.6  находящийся в репозитории jessie  стало хуже чем wine1.4 который был в репозиториях wheezy, хотя и последний был очень далёк от совершенства. Некоторые пытались вручную установить старый wine1.4  на jessie но как несложно догадаться этому мешают проблемы зависимостей. Некоторые пользователи попытались бы использовать на этот случай пакеты из ppa ubuntu, действительно в них лежат более свежие версии wine1.7** с поддержкой эмуляции даже windows 10 но установить эти бинарные пакеты на debian  не получится не при каких обстоятельствах из за тех же зависимостей которые в большинстве своём вычисляются автоматически debhelper  при сборке в бинарные пакеты с помощью fakeroot.
Справедливости ради надо отметить что несмотря на объём исходников и большое количество сборочных зависимостей бэкпортирование wine не составляет особого труда  так как приложение совершенно одинаково устанавливается что в ubuntu что debian не имеет специфических конфигурационных файлов и стартовых скриптов а все необходимые для сборки инструменты и библиотеки имеются в debian разве что часть библиотек представлены другими пакетами.
Разберём подробно процесс бэкпортирования wine 1.7.
В нашей виртуальной машине,  строго 32 битной архитектуры, где уже установлена dpkg-dev
создадим каталог для сборки
mkdir -p ~/build/wine
cd   ~/build/wine
Что бы не изголяться с добавлением в sources.list нашей сборочной машины
deb-src http://ppa.launchpad.net/ubuntu-wine/ppa/ubuntu vivid main
и не добавлять ключ для этого репозитория
Просто напросто пройдём по адресу  https://launchpad.net/~ubuntu-wine/+archive/ubuntu/ppa
переходим по ссылке View package details и находим на второй странице  wine1.7 - 1:1.7.55-0ubuntu1
загрузим сорцы при помощи wget
wget https://launchpad.net/~ubuntu-wine/+archive/ubuntu/ppa/+files/wine1.7_1.7.55-0ubuntu1.debian.tar.xz
wget https://launchpad.net/~ubuntu-wine/+archive/ubuntu/ppa/+files/wine1.7_1.7.55-0ubuntu1.dsc
wget https://launchpad.net/~ubuntu-wine/+archive/ubuntu/ppa/+files/wine1.7_1.7.55.orig.tar.bz2
Распакуем исходники с помощью утилиты dpkg
dpkg-source -x wine1.7_1.7.55-0ubuntu1.dsc
с удивлением обнаруживаем что у нас образовалась папка wine1.7-1.7.55   
переходим в неё
cd wine1.7-1.7.55   
для удобства работ по редактированию исходников нам нужен midnight commander установим его
apt-get install mc
проявим смекалку и посмотрим какие неудовлетворённые сборочные зависимости имеет загруженный нами исходник.
dpkg-checkbuilddeps
в ответ получаем Unmet build dependencies: солидный список пакетов   после | указаны так называемые replase (заменяющие) пакеты.
Оптом или в розницу ставим пакеты  из списка до тех пор пока не получим от  apt неутешительный ответ что для пакета такого то не найден кандидат для установки. Вот они зависимости . На практике камнем предкновения стал пакет libgnutls-dev в debian его аналогом является libgnutls28-dev
с помощью mc   открываем /debian/control и приступаем к редактированию меняем libgnutls-dev на libgnutls28-dev
Уже забывается все ли это пакеты но поступаем подобным образом до тех пор пока все зависимости не будут удовлетворены. Не забываем что всегда если в сборочных зависимостях присутствует заголовок -dev в зависимостях или хотя бы рекомендованих будет основной пакет ! Везде где в установочных зависимостях находим libgnutls26 меняем на libgnutls28 там же правим версию dpkg  на ту что в репозитории jessie проверяем досконально все остальные установочные зависимости для каждого  из собираемых бинарных пакетов обнаруживаем winetricks он нам не нужен, так как проще скачать последний скрипт из git и положить в /usr/bin чем собирать лишние пакеты. Удаляем winetricks из зависимостей.
Обратим внимание на установочные зависимости, присутствоет строка
depends:    ${shlibs:Depends},
она объясняет почему пакет для debian должен быть собран именно на таком же debian.
Если очень хочется мэйнтейнерских лавров и на машине имеется ключ шифрования что бы подписать пакеты можно изменить строку
Maintainer: Scott Ritchie <scottritchie@ubuntu.com>
устраивающим вас образом. Лично мне это не нужно. Сохраняем изменения , выходим из mc
Исправим принадлежность будущих пакетов  сделаем их типа дебиановскими
dch -i
В верху открывшегося файла видим
wine1.7 (1:1.7.55-0ubuntu1.1) UNRELEASED; urgency=medium
правим её до шаблонного для debian состояния или как вам нравится, главное не переусердствовать !
wine1.7 (1:1.7.55-0deb8u1) jessie; urgency=medium
можете по образу и подобию добавить информацию о себе как о сопровождающем но это необязательно, сохраним изменения.
Если мы всё сделали внимательно и ни где не накосячили наступает кульминация
dpkg-buildpackage -rfakeroot -D
идём спокойно ужинать, пить чай, посмотреть киношку или заниматься домашними делами. Процесс достаточно длительный  но в итоге ~/build/wine получаются бинарные   и сорцовые пакеты уже для debian/
wine-mono и wine- gecko собираются аналогично там даже не надо править зависимости.
Всё на первый взгляд совсем не сложно, но не стоит обольщаться. В другой раз сборка программы весом в несколько мегабайт может вскипятить мозги.

Основы компиляции из исходных кодов.


Наверное нет смысла переписывать интернет, просто посоветую самостоятельно ознакомиться с самыми распространёнными системами сборки. Выбор каждой из них определяет автор программы которую мы решили собрать из исходного кода. Естественно документация по этому поводу обязательно находится в  README или INSTALL в исходниках.

Autotools возможно самая распространённая https://ru.wikipedia.org/wiki/Autotools

Automake по личным наблюдениям используется для сборки небольших программ, как раз тот случай когда мы не наблюдаем скрипта configure а в документации упоминается только make https://ru.wikipedia.org/wiki/Automake

Cmake  как и две предидущие системы является стандартной утилитой для debian,  честно говоря сборка с её использованием достаточно сложна и трудоёмка. https://ru.wikipedia.org/wiki/CMake

Waf получает в последнее время распространение для сборки достаточно экзотичных проетов , не является инструментом debian но для выполнения сборки достаточно просто сама устанавливается из исходников https://ru.wikipedia.org/wiki/Waf

Маленькие хитрости, облегчающие жизнь.

В debian своя отличная поисковая система, работающая по алгоритму:
Сообщение об ошибке — не найден /путь/до/ файл такой то.so1
https://packages.debian.org/ru/jessie

Ищем  в содержимом пакетов , просто вставив в поисковую строку путь и название искомого файла. В результате получаем название пакета ( как правило это заголовок ) который нам необходимо установить через apt для устранения ошибки.
Если немного расширить поиск то мы без труда выясним все зависимости искомого пакета и даже название пакета исходного кода. Это будет очень полезной информацией если мы для каких то целей будем вынуждены бэкпортировать каике либо пакеты из testing , sid или даже ubuntu ни чего нельзя исключать в этой жизни когда человек загорелся какой то целью.
Такая рутина однако отнимает время и в debian предусмотрены консольные инструменты для экономии этого времени.

Утилита apt-file

apt-get install apt-file
apt-file update

что бы обновить базы данных утилиты в соответствии с подключенными источниками.
Например мы собираем некое мультимедийное приложение и подключили источник deb-multimedia.
apt-file search /путь/до/файл
Утилита выдаст сообщение о том в каких пакетах содержится недостающий для сборки файл, выберем как правило заголовочный пакет -dev и установим его через apt.

Утилита auto-apt призвана ещё более автоматизировать процесс сборки. Установим её

apt-get install auto-apt
auto-apt update
auto-apt updatedb && auto-apt update-local

Теперь поиск недостающего заголовочного файла можно сделать, например, так:
auto-apt search Xlib.h

Допустим мы собираем программу но нам мало что известно о её сборочных зависимостях.
В классическом варианте скрипт configure  будет останавливаться и выдавать сообщение о отсутствующих в системе пакетах, необходимых для сборки исходника до тех пор пока мы не установим всё необходимое. Если мы используем auto-apt то можем вместо классического
./configure --prefix=/usr
подать команду
auto-apt run ./configure --prefix=/usr

В результате система предложит установить все недостающие сборочные зависимости и если мы согласимся всё будет установлено и скрипт configure  должен отработать без ошибок.
В том случае если мы просто устанавливаем программу из исходного кода
остаётся собрать
make
и установить
make install


Checkinstall
Стадартная утилита в debian но я не сторонник её использования.
Хотя собранная программа упаковывается в пакет очень просто , достаточно ответить утвердительно на пару несложных вопросов и даже собранный с помощью  checkinstall  пакет можно сразу не устанавливать в систему если выполнить команду с ключём --install=no с ключём --install=yes  или без всяких ключей пакет будет установлен в систему по окончании сборки.
sudo checkinstall --install=no
Пакет  который мы обнаруживаем в папке с исходниками получается неполноценным , содержимое подкаталога debian в пакете составляет только файл control всей полезной информации в котром только об архитектуре пакета, не прописывются даже зависимости. Системные файлы при распаковке такого пакета появляются в /usr/local и /usr/share.
Такие пакеты могут конечно созданы для упаковки небольших программ не имеющих каких либо специфических зависимостей и такие пакеты собираются преимущественно в той системе куда будут установлены. Пожалуй единственным плюсом перед make install будет возможность  удалить пакет стадартными средствами dpkg и надстроек и не оставлять в системе строительный мусор.

Собираем по правилам простенький deb пакет.

Не станем обольщаться что мы уже всё знаем и умеем, это совсем не так , тем не менее пора попробовать на практике проверить свои способности, при чём не на кого не надеясь и не имея шпаргалки в виде готовых deb-src.
Не будем сразу ставить сверхзадачу, соберём одиночный deb пакет  с маленькой игрушкой.
Идем на http://sourceforge.net/directory/system-administration/emulators/os%3Alinux/? и выбираем объект для тренировки мозгов.
Я ткнул пальцем в небо ( взгляд упал на иконку) и выбрал эмулятор каких то древних игровых консолей DGen.
Скачал и поместил в каталог где будет производиться сборка в моей виртуальной машине
dgen-sdl-1.33.tar.gz
Распаковал и перешёл в папку с исходниками
tar -xvf  dgen-sdl-1.33.tar.gz
cd dgen-sdl-1.33

Среда была совершенно минимальной, для сборки установил инструменты, да и всё остальное буду делать по убунтовскому вики (есть подозрение что оно форкнуто у дебианщиков  ) http://help.ubuntu.ru//wiki/сборка_пакетов?redirect=1

apt-get install autoconf automake libtool autotools-dev dpkg-dev fakeroot

Знакомимся с содержимым исходников: в  README замечаем что для работы эмулятора необходима библиотека sdl версии 1.0 или свежее находим заголовок для неё и устанавливаем

apt-get install libsdl2-dev
тянет за собой множество зависимостей.

./autogen.sh
./configure  --prefix=/usr
make
на удивление проходит без проблем, что очень удивило, и если бы мы просто собирали программу из исходников следующим шагом было бы
make install
но мы поставили себе цель собрать deb  пакет
по этому займёмся дебианизацией, по крайней мере созданием шаблона
apt-get install dh-make

dh_make —createorig


жмём s   и пару раз ввод,
наблюдаем появление в папке с распаковаными исходниками нового каталога debian а рядом с исходниками новый архив
dgen-sdl_1.33.orig.tar.xz
за тем любым удобным текстовым редакторам немного правим /debian/control
заполнив информацию о сборщике пакета и его е-майл  ( целесообразно при наличии  ключа для подписи) .
Добавляем вычисленную нами сборочную зависимость
Build-Depends: debhelper (>= 9), autotools-dev, libsdl2-dev
и соответственно ей установочную зависимость
Depends: ${shlibs:Depends}, ${misc:Depends}, libsdl2-2.0-0
обязательно проверяем /debian/rules
в принципе этого достаточно для сборки одиночного бинарного пакета
приступаем к сборке вылезла ошибка

dpkg-shlibdeps: error: no dependency information found for /usr/lib/i386-linux-gnu/libarchive.so.13 (used by debian/dgen-sdl/usr/bin/dgen)

ищем в файлах пакетов debian /usr/lib/i386-linux-gnu/libarchive.so.13
это  libarchive13 установим его и допишем в /debian/control  как сборочную зависимость
со второй попытки выяснилось что не найден /usr/lib/i386-linux-gnu/libSDL-1.2.so.0
установим и допишем в сборочные зависимости libsdl1.2-dev
и соответственно в установочные.
libsdl1.2debian
Пакет успешно собран, установлен и даже  работает. Кто бы ещё за меня поиграл  а я не умею..

Заметим игрушка запущена на фоне enlightenment e20 . Этот оконный менеджер так же собран в deb пакеты специально для jessie и установлен по всем правилам чер

[ferum]

Come updone

Ранее мы с вами рассмотрели как устроен пакет debian, а на примере бэкпортирования имели возможность рассмотреть устройство deb-пакета в ubuntu, и правильно заметили что различия минимальны. Но так ли однозначно всё в жизни? Сам всегда интересуюсь и много раз читал восторженные оды о различных форках debian, вроде как взяли за основу и сделали лучше. Конечно они разные, есть Kali и Kanotix, но есть и Point и Antix и многие другие. У каждого своя команда. Интересно посмотреть как осуществляется сборка пакетов в таких дистрибутивах, будем справедливы что многие проекты по непонятным причинам не выкладывают свои deb-src, попробуем догадаться.
В период тестирования jessie  у нас на форуме была статейка об использовании польского дистрибутива sparkylinux. Я тогда уже заинтересовался оконным менеджером e19 который был включён в его состав. Sparkylinux попробовал на виртуальной машине, а на тестовый винчестер поставил базовый jessie и подключил репозиторий sparkylinux
http://sparkylinux.org/wiki/doku.php/repository
При установке E19 обнаружил что пакет очень большой по размеру и имеет совершенно другие зависимости, нежели хотя бы Е17 или Е19 для ubuntu. Посмотрим почему.
Для этого нам придётся добавить репозиторий в наш sources.list
nano /etc/apt/sources.list
добавим строку
deb http://sparkylinux.org/repo testing main
а для того что бы просто скачать пакет с ключём даже не будем заморачиваться.
Как и в прошлый раз обновим информацию об источниках
aptitude update
перейдём в папку tmp которую использовали в прошлый раз и скачаем пакет ( сейчас уже e20 )
aptitude download e20
Не забудем убрать строчку из sources.list
Сейчас у меня система 64-битная поэтому скачался e20_0.20.99.20870-1_amd64.deb
Снова будем разбирать пакет
ar vx e20_0.20.99.20870-1_amd64.deb
распакуем control.tar.gz
tar -xzvf control.tar.gz
и рассмотрим появившиеся файлы.
Как будто бы всё хорошо: присутствуют control,  postinstall, postrm, md5sums .
При внимательном рассмотрении обнаружим что второй архив data имеет другое расширение .tar.xz
Распакуем  data.tar.xz
tar -xpJf data.tar.xz
Что мы видим - папка opt, в ней e20 и далее разветвление bin etc include lib share естественно с подпапками и файлами в них.
Рядом с opt папка usr c подпапками bin lib share внутри котрых внимание! Одни символьные ссылки.
Скажете как такое вообще может быть? На самом деле всё очень просто.
По крайней мере года четыре или пять тому назад на официальном сайте enlightenment была инструкция по сборке их продукта в /opt . Тогда ещё не было понятия EFL (enlightenment fondation libraries) а были eina eit eeze и так далее, каждая собиралась отдельно в определённом порядке, но по общим правилам. Начиная с
./configure --prefix=/opt/e17
думаю теперь вам стало понятней мэйнтейнер в sparkylinux старой закалки и надо сказать не плохо знает linux, но не очень-то уважает политику debian относительно сборки пакетов.
Собственно говоря он поставил систему, собрал через make весь e20, установил его.
Потом из рабочей системы скопировал всё что необходимо для работы enlightenment в одну папку (предположим она называлась tempprog), это объясняет наличие opt и usr, а ещё положил туда каталог debian, в котором разместил control, postinstall, postrm которые обеспечат установку и удаление пакета стандартными средствами и представят информацию о пакете и его авторе. Всё что ему оставалось завернуть свой салат в пакет с помощью dpkg.
Находясь в каталоге tempprog выполнить команду
dpkg-deb -b ./ ~/.
при этом собранный dpkg пакет появится каталогом выше. Полезная статья по этому поводу
http://mydebianblog.blogspot.ru/2013/10/deb-debian.html кстати там есть мой комментарий от 13 февраля 2014.
Получается за чем делить всё на пакеты, писать сложные rules мучиться с  капризным fakerrot
можно просто собрать и упаковать. В пользу моего маленького  следствия отсутствие в sparky пакета python-efl ведь он нужен только для сборки enlightenment, а для работы нет.
Кстати в теории если мы собираем из исходников программу необязательно устанавливать её в систему, можно имитировать инсталляцию в предварительно подготовленную в каталоге сборки папку, как вариант ~/build/tempprog
Тогда схема сборки пакета будет очень проста, к примеру:

Код Выделить Развернуть


./configure --prefix=/usr
make
make install DESTDIR=/build/tempprog

За тем просто добавить в ~/build/tempprog подкаталог debian и заполнить последний
файлами control и необходимыми для работы программы скриптами.
После чего из tempprog выполнить
dpkg-deb -b ./ ~/.

Полученный пакет будет иметь название, версию и архитектуру, те что прописаны в файле control. Вот такая она - dpkg.
Едва ли стоит бросаться клепать пакеты столь нехитрым способом, но знать о его существовании не повредит.

[endru]

wget https://launchpad.net/~ubuntu-wine/+archive/ubuntu/ppa/+files/wine1.7_1.7.55-0ubuntu1.debian.tar.xz
 wget https://launchpad.net/~ubuntu-wine/+archive/ubuntu/ppa/+files/wine1.7_1.7.55-0ubuntu1.dsc
 wget https://launchpad.net/~ubuntu-wine/+archive/ubuntu/ppa/+files/wine1.7_1.7.55.orig.tar.bz2

вообще есть утилита dget, скармливаешь ей ссылку на dsc файл и она сама подтягивает нужные файлы.

Открыть содержимое (спойлер)

dget https://launchpad.net/~ubuntu-wine/+archive/ubuntu/ppa/+files/wine1.7_1.7.55-0ubuntu1.dsc

[свернуть]

[kol1978]

Спасибо авторам за инфу! - очень информативно, познавательно.
Постараюсь быть краток: у установленной CAELinux 2020 (не только у неё) проблема с работой на моём ПК (сеть и прочее...), как сейчас однозначно выяснилось (после установки Debian 12 Книжный червь) что проблема именно в программной несовместимости с моим ПК...Debian 12 (Книжный червь) - работает отлично. При этом проблема решалась - работой в Oracle VM VirtualBox. Но для Debian 12 и Kali  проблема с ф. драг_дроп...и нужные пакеты доступны только в Debian10Buster (например - Code_Aster... хотя calculix допустим есть...). Поэтому нужна помощь - с установкой пакетов (список есть) на Debian 12 и Kali (кали под вопросом) программ из других дистрибутивов и что бы все работало как надо на 12ом и можно было потихоньку припиливать одну прогу к другой. Подскажите наиболее правильный порядок действий с примерами команд(направьте )?

[yoric]

Для этого нам придётся добавить репозиторий в наш sources.list
nano /etc/apt/sources.list
добавим строку
deb http://sparkylinux.org/repo testing mainа для того что бы просто скачать пакет с ключём даже не будем заморачиваться.
Как и в прошлый раз обновим информацию об источниках
aptitude update
перейдём в папку tmp которую использовали в прошлый раз и скачаем пакет ( сейчас уже e20 )
aptitude download e20
Не забудем убрать строчку из sources.list

В дебиане, во всяком случае, репоз доступен по ftp, http и прочим ..pp. Так что можно просто подключиться любым клиентом (даже mc) и просто скачать, ну как максимум прочесать packages.

[ferum]

kol1978  боюсь версия python  в современных дистрибутивах не та... хотя разработчики должны бы +- адаптировать salome meca  к существующим реалиям. К сожалению проекты имеют свойство умирать со временем, особенно не широкого потребления. Есть кино https://www.youtube.com/watch?v=eohq8t2pf0I там вроде всё показано, но стоит понимать что названия скачиваемых файлов и сборочных зависимостей могут отличаться.
Готовых пакетов очевидно нет.