Добрый день. Я задался таким вопросом - как правильно собрать для Debian Jessie .deb пакет с некоторой прогой?

В случае, если проги в репозиториях debian принципиально нет, как я понимаю, есть два варианта развития событий: либо я подготавливаю полноценную «дебианизацию» в соответствии с инструкцией по созданию пакетов Debian, либо использую checkinstall. Вопрос: Если речь идёт только о личном использовании, то есть ли смысл идти длинным путём (дебианизация), или checkinstall является оптимальным решением? Как я понимаю, checkinstall позволит создать .deb пакет из уже собранной программы и заполнить всю ту информацию в пакете, которая должна там быть, в то время как для полноценной дебианизации придётся писать много разного в том числе и для сборки, а значительная часть информации не попадёт в .deb пакет, т.е. окажется для меня ненужной.

Если пакет есть в репозиториях debian, но мне нужна более новая версия, то имеет ли смысл брать готовый каталог debian и адаптировать под новую версию, или лучше самому (возможно) наложить патчи из debian, а потом собрать и заcheckinstall'ить? Заранее спасибо.

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

• XEmbed-трей (legacy трей):
  Самый первый стандарт трея в UNIX-системах, основан на технологии встраивания в X11. Великая суть: приложение создаёт окно-значок и встраивает в нужную область, просто и сердито.
  
  Недостатки:
  • Контролировать значок может только само приложение;
  • Не учитывается, что областей трея может быть несколько (на нескольких мониторах);
  • Привязано к X Window System.
  Достоинства:
  • Поддерживается почти везде (кроме Unity и WingPanel (Pantheon));
  • Поддерживают почти все приложения.
  Не самый плохой стандарт, вполне можно считать чем-то вроде UNIX-way, но сейчас как-то отжило своё (не UNIX-way, а XEmbed-трей).
  
  
• SNI-трей (org.freedesktop.StatusNotifierItem):
  Стандарт, впервые представленный в KDE SC 4.4 для решения проблем с XEmbed-треем.
  Взаимодействие приложения с областью трея происходит через dbus, при этом сам значок рисуется областью трея, и при желании область может значок заменять на другой и т.д. Например, в KDE сейчас стандартные приложения типа KMix в трее имеют белые значки, которые делаются на уровне Plasma, а не на уровне самих приложений.
  Хоть StatusNotifierItem и был представлен проектом KDE, наибольшую известность получил в Ubuntu, ибо… в KDE особо не видно разницы :-).
  В свою очередь, в Ubuntu 10.04 были продемонстрированы библиотека libappindicator и ayatana-индикатор indicator-application, которые и реализуют SNI-трей. Собственно, в Ubuntu стал известен не столько StatusNotifierItem/appindicator, сколько сами по себе ayatana-индикаторы, но разработчики приложений таки опираются именно на appindicator.
  Также в Ubuntu есть плагин к трею Qt4 sni-qt, который все Qt4-приложения переводит на SNI-трей, но главная проблема — нужен патч kubuntu_14_systemtrayicon.diff, который так и не попал в upstream Qt4 (в Qt5 таки попал, но сам sni-qt ещё не адаптирован для него).
  
  Недостатки:
  • Меньшая поддержка, нежели у XEmbed-трея;
  • Меньшая поддержка среди приложений, что, впрочем, сильно улучшается со временем из-за того, что Unity не поддерживает XEmbed-трей.
  Достоинства:
  • Стандарт freedesktop.org;
  • Поддерживается Unity, MATE, Xfce (через indicator-application);
  • Поддерживается WingPanel, Cairo-Dock;
  • Поддерживается GNOME Shell (через расширение, если оно не отвалилось, опять);
  • Не привязано к какому-либо графическому серверу (да и что может помешать приложению из XWayland по dbus слать значок к области трея в Wayland :3?);
  • Гибкость и масштабируемость (отдельно учитывать в стандарте многомониторные конфигурации даже не нужно, всё отлично работает само по себе);
  • Поведение значка определяется самой областью трея.
  Можно сказать, это и есть идеальный трей, стандарт, на который и следует опираться, если не хочется оказаться за бортом (хотя бы вместе с X.Org'ом). Тем более, libappindicator вполне умеет рисовать и XEmbed-значки, если нет области SNI-трея.
  
  
• Ayatana-индикаторы:
  Одновременно с indicator-application в Ubuntu 10.04 были представлены и сами индикаторы в рамках проекта Ayatana.
  Сказать — зачем, как-то особо не получается, все индикаторы (indicator-sound, indicator-bluetooth и т.д., да даже indicator-appmenu) вполне можно было оформить и в виде StatusNotifierItem.
  Большинство компиляций индикаторов, кстати говоря, даже содержат в большей степени appindicator'ы, нежели ayatana-индикаторы, ведь создаватели компиляций всё равно разницы не видят.
  
  Недостатки:
  • Не так и много дистрибутивов внесли индикаторы в свои репозитории (в openSUSE их нет, в Debian они есть);
  • Больше похожи на прослойку между Unity, MATE, Xfce и appindicator; в общем, не нужны;
  • Индикаторы зависят от Gtk3 или Gtk2 (причём, не все индикаторы имеют поддержку Gtk2; например, indicator-appmenu не имеет);
  Достоинства:
  • Поддерживаются Unity, MATE (через официальный mate-indicator-applet), Xfce (через xfce4-indicator-plugin);
  • Само собой, гибкость на уровне SNI-трея;
  • Привязки к графическому серверу также нет (ayatana-индикаторы, скоро на всех Mir'ах страны!).
  Малонужная штука, но из-за того, что indicator-applet (который и был форкнут в mate-indicator-applet) и xfce4-indicator-plugin были написаны в рамках Ubuntu… в общем, если хочется SNI/appindicator на MATE и Xfce (а кто его не хочет :3?), то и ayatana-индикаторы тоже нужны.