\section{Справяне с проблеми - \textit{ръчно}}
    
\subsection{Справяне с някои конфигурационни проблеми чрез
  maintainer's scripts}


Това е пример с цел демонстрация и не е задължително посоченият пакет
да има проблеми;-).  Има ситуации, в които \textit{автоматичното}
конфигуриране и преконфигуриране на пакети няма да е достатъчно, за
това ще се намесим и \textit{самостоятелно} или \textit{ръчно}.


Нека предположим, че ползвате пакети от Unstable (Sid), experimental
или някое неофициално място. Освен това сте попаднали на пакети с
недостатъчно изтествани и усъвършенствани maintainer scripts, поради
които \man{apt-get}{8} се оказва, че изчаква \man{dpkg}{8}, който пък
от своя страна изчаква някой такъв \texttt{post*} и/или \texttt{pre*}
скрипт, идващ с дадения пакет. Може да се окаже, че скриптът е
некоректен и въобще да чака във висящо състояние до безкрай,
блокирайки \man{dpkg}{8}, а оттам и \man{apt-get}{8}.  Те не са
увиснали, а изчакват, например, даден лош \texttt{postinst} скрипт да
завърши успешно своето изпълнение. Може да се окаже, разбира се, че
това наистина не е по вина на самите скриптове, а на някоя програма,
която те пък извикват или се опитват да стартират.
         

Предназначението на тези скриптове (както между другото е видно и от
техните имена), намиращи се в \texttt{/var/lib/dpkg/info/} и извиквани
от \man{dpkg}{8}, е следното:
         
\begin{itemize}
  
\item \texttt{\textit{пакет}.preinst}: изпълнява се \textit{ПРЕДИ}
  \textbf{ИНСТАЛАЦИЯТА} на пакета
  
\item \texttt{\textit{пакет}.postinst}: изпълнява се \textit{СЛЕД}
  \textbf{ИНСТАЛАЦИЯТА} на пакета
  
\item \texttt{\textit{пакет}.prerm}: изпълнява се \textit{ПРЕДИ}
  \textbf{ПРЕМАХВАНЕТО} на пакета
  
\item \texttt{\textit{пакет}.postrm}: изпълнява се \textit{СЛЕД}
  \textbf{ПРЕМАХВАНЕТО} на пакета

\end{itemize}


Например, нека кажем, че такава ситуация се получава при:
         
\begin{verbatim}
# apt-get install scrollkeeper -t unstable
\end{verbatim}

   
Чакате доста дълго време, наблюдавате процесите \man{apt-get}{8},
\man{dpkg}{8}, \texttt{scrollkeeper.postinst} с \texttt{ps auxfw} и
\texttt{top}, и като че ли изглежда не се върши никаква полезна
работа. След като наистина се убедите, че това е така, ще се опитаме
да решиме нещата в ход. Хвърляте едно око на самия postinst-скрипт,
който за пакета \deb{scrollkeeper} е в
\texttt{/var/lib/dpkg/info/scrollkeeper.postinst}. В случая виждаме,
че този скрипт пък извиква друг такъв, \texttt{scrollkeeper-rebuilddb
  -q}, разглеждаме набързо неговата справочна страница
\man{scrollkeeper-rebuilddb}{8} и се убеждаваме, че временно е напълно
безопасно и да не бъде изпълнен, така че можем да го коментираме в
\texttt{scrollkeeper.postinst}, за да мине инсталацията пред
\man{dpkg}{8} и \man{apt-get}{8} успешно, пък после ще се опитаме да
открием проблемите на самия \man{scrollkeeper-rebuilddb}{8},
стартирайки го например с опция \texttt{-v} (verbose). Коментираме и
запазваме промените.  Дори можем да прибавим в postinst-скрипта и
едно:

\begin{verbatim}
echo "'this is a temporary fix to unblock dpkg & apt"'
\end{verbatim}


Следва направо kill на \textit{apt-get}, той от своя страна ще убие
процесите \texttt{dpkg} и \texttt{scrollkeeper.postinst}. Забележете,
че пред \man{dpkg}{8} все още не е регистрирана успешна инсталация на
този пакет и при изпълнението на \texttt{apt-get install} или
\texttt{dpkg -i} ще се препоръча да се изпълни първо:
         
\begin{verbatim}
# dpkg --configure -a
\end{verbatim}
        

Ако го изпълним без да сме редактирали postinst-скрипта, ще получим
пак същия неуспешен резултат, за това го правим след промени в него.
Изпълняваме го и вече няма кое да спре завършването на скрипта
\texttt{scrollkeeper.postinst}, оттам \man{dpkg}{8} и \man{apt-get}{8}
завършват успешно работа и са разблокирани за по-нататъчни процедури.
Започваме да търсим проблема на самия скрипт
\man{scrollkeeper-rebuilddb}{8}, разглеждайки кода му и стартирайки го
с разни аргументи, като може дори да се наложи да направите промени и
в самия него, след което пак да откоментираме достъпа до него от
\texttt{scrollkeeper.postinst} и тестваме как ще работи той, например
с:
         
\begin{verbatim}
# dpkg-reconfigure skrollkeeper
\end{verbatim}
         

И така, докато постигнем някакъв по-задоволителен резултат. Това не
сте длъжни да го правите, но за спорта си заслужава. След това, ако
имате желание, можете да дръпнете debian source package и да внесете
съответните подобрения, да ги предложите на maintainer-а на пакета,
или просто да регистрирате бъг срещу този пакет от дадено ниво (вкл. и
\texttt{wishlist}) на \hlink{http://bugs.debian.org}{http://bugs.debian.org}, 
ако вече това не е направено, разбира се.


В случая е даден прост пример, но можете да се сблъскате с истински
предизвикателства и след като разблокирате (освободите) \man{dpkg}{8}
и \man{apt-get}{8}, от ход да потърсите и цялостно решение. Такива
\texttt{preinst}-, \texttt{postinst}-, \texttt{prerm}-,
\texttt{postrm}- скриптове, разбира се, ще намерите за всеки debian
binary package, също така и в debian source package, от който е
получен, както и в
\texttt{/var/lib/dpkg/info/\textit{пакет}.\textit{скрипт}}.


Аналогично, вместо \man{apt-get}{8} и \man{dpkg}{8} да изчакват
скриптовете, които не са си свършили работата по някаква причина, може
направо да връщат грешка, при което да получите нещо от вида на:

\begin{verbatim}
apt-get remove xscreensaver
.. .. .. .. .. .. .. .. .. .. 
dpkg: error processing xscreensaver (--remove):
 subprocess post-removal script returned error exit status 127
Errors were encountered while processing:
 xscreensaver
\end{verbatim}

 
Процедурата е напълно аналогична на горeописаната, само че сега
скриптовете направо приключват работа и уведомяват \man{dpkg}{8}, че
излизат с даден статус. В този пример очевидно трябва да се разправим
със скрипта \texttt{/var/lib/dpkg/info/xscreensaver.postrm}, така че
той да приключва работата си успешно. След което регистрираме това,
изпълнявайки:

\begin{verbatim}
# dpkg-reconfigure xscreensaver
\end{verbatim}