грамотная установка отсутствующего в репозитарии пакета

[oermolaev]

Как правильно (грамотно) установить отсутствующий в репозиториях wheezy пакет, в то время как он имеется и в jessie, и в sid?
В частности, речь идет о havp

[gardarea51]

Подключить репозитории jessie или sid, выполнить apt-get update. Затем установить пакет:

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

apt-get -t jessie install havp

И еще было бы неплохо задать wheezy дефолтным релизом, чтобы все устанавливаемые пакеты (и обновления системы) по умолчанию брались для wheezy, это делается например так:

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

# cat /etc/apt/apt.conf.d/00DefaultRelease
APT::Default-Release "wheezy";


Файл /etc/apt/apt.conf.d/00DefaultRelease скорее всего нужно будет создать.

[oermolaev]

gardarea51, спасибо, вариант рабочий. И даже прошлым летом вполне удался на реальном шлюзе. Но не в этот раз. Новый havp потянул за собой обновление уже имеющихся библиотек, которое повлекло какие то ошибки, с которыми я не стал долго разбираться, а обновил всю систему до jessie, а затем и переустановил "по чистой". Всё шло замечательно, jessie понравилась, но когда очередь дошла до squid3 v3.4.8, оказалось что последний ни в какую не хочет слушать http_port. На этот раз я затратил гораздо больше усилий на решение проблемы, но безуспешно.
Тогда "по накатанной", тем же путём установил проверенный ранее squid3 v3.1.20 из wheezy. Оказалось что он и в jessie успешно работает.
В связи с изложенным, из первого вопроса напрашивается второй:
Насколько такие бесшабашные поступки, а именно установка пакетов из разных релизов, оправданы и допустимы в Debian? Или же это стандартная практика, судя по имеющейся опции в aptitude:

-t [release]   Задать выпуск, из которого должны быть установлены пакеты.

?

[ferum]

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

[gardarea51]

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

[oermolaev]

правильней сделать бэкпорт

Создание бэкпорта видимо наилучший вариант

посоветуйте где почитать про это?

[ferum]

http://gq.net.ru/2007/03/16/building-deb-packages/

[oermolaev]

ferum, спасибо за направление в нужную сторону. Нашел более официальный источник: DebianBuildPackages

gardarea51, ferum, спасибо за науку и помощь, самую первую задачу (с havp) удалось реализовать на боевой машине.

Ещё вопрос на эту же тему:

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

Кто определяет эту возможность? Как отделить собственные ошибки от "возможно/невозможно"?

Так, например, в jessie мне удалось собрать squid2.7, а squid3 (от wheezy) не получилось с ошибками типа:

configure: error: Cannot find cppunit at /usr
/usr/share/cdbs/1/class/autotools.mk:42: ошибка выполнения рецепта для цели «debian/stamp-autotools»

Как искать решение для подобных ошибок?

[ferum]

Бэкпортируется конечно не всё, зависит от взаимной совместимости компиляторов, библиотек и исходника. Те кто знаком с программированием эту совместимость расширяют посредством патчей ( правкой исходника ).
Перед тем как приступить к сборке пакета иногда полезно попробовать просто собрать из исходника ./configure или ./autogen.sh && make или cmake ( узнаётся из прилагаемой документации). В большинстве случаев сразу не собирается ругаясь на отсутствие в системе заголовков например в вашем случае необходимо установить  libcppunit-dev
и перезапустить сборку.
Главные помощники в разгадывании ошибок утилита apt-file  и конечно гугль.
Потом можно заниматься и сборкой деб пакета, здесь главное сообразить что писать в /DEBIAN/rules не всегда удаётся собрать не делая изменений но обычно ругань при неудачной сборке пакета наводит на правильное решение.
Как это не прискорбно ubuntu со своими ppa всегда впереди по наличию редкого или экзотического софта и приходится заимствовать исходники там. При этом выбираем исходник от релиза в котором совпадает с нашим версия компилятора а в некоторых случаях желательно и ядра.