Напред: Конфигуриране на пакети - Up: Инструкции за работа с Назад: Контролиране на избора на Съдържание
Това е пример с цел демонстрация и не е задължително посоченият пакет да има проблеми;-). Има ситуации, в които автоматичното конфигуриране и преконфигуриране на пакети няма да е достатъчно, за това ще се намесим и самостоятелно или ръчно.
Нека предположим, че ползвате пакети от Unstable (Sid), experimental или някое неофициално място. Освен това сте попаднали на пакети с недостатъчно изтествани и усъвършенствани maintainer scripts, поради които apt-get(8) се оказва, че изчаква dpkg(8), който пък от своя страна изчаква някой такъв post* и/или pre* скрипт, идващ с дадения пакет. Може да се окаже, че скриптът е некоректен и въобще да чака във висящо състояние до безкрай, блокирайки dpkg(8), а оттам и apt-get(8). Те не са увиснали, а изчакват, например, даден лош postinst скрипт да завърши успешно своето изпълнение. Може да се окаже, разбира се, че това наистина не е по вина на самите скриптове, а на някоя програма, която те пък извикват или се опитват да стартират.
Предназначението на тези скриптове (както между другото е видно и от техните имена), намиращи се в /var/lib/dpkg/info/ и извиквани от dpkg(8), е следното:
Например, нека кажем, че такава ситуация се получава при:
# apt-get install scrollkeeper -t unstable
Чакате доста дълго време, наблюдавате процесите apt-get(8), dpkg(8), scrollkeeper.postinst с ps auxfw и top, и като че ли изглежда не се върши никаква полезна работа. След като наистина се убедите, че това е така, ще се опитаме да решиме нещата в ход. Хвърляте едно око на самия postinst-скрипт, който за пакета scrollkeeper е в /var/lib/dpkg/info/scrollkeeper.postinst. В случая виждаме, че този скрипт пък извиква друг такъв, scrollkeeper-rebuilddb -q, разглеждаме набързо неговата справочна страница scrollkeeper-rebuilddb(8) и се убеждаваме, че временно е напълно безопасно и да не бъде изпълнен, така че можем да го коментираме в scrollkeeper.postinst, за да мине инсталацията пред dpkg(8) и apt-get(8) успешно, пък после ще се опитаме да открием проблемите на самия scrollkeeper-rebuilddb(8), стартирайки го например с опция -v (verbose). Коментираме и запазваме промените. Дори можем да прибавим в postinst-скрипта и едно:
echo "'this is a temporary fix to unblock dpkg & apt"'
Следва направо kill на apt-get, той от своя страна ще убие процесите dpkg и scrollkeeper.postinst. Забележете, че пред dpkg(8) все още не е регистрирана успешна инсталация на този пакет и при изпълнението на apt-get install или dpkg -i ще се препоръча да се изпълни първо:
# dpkg --configure -a
Ако го изпълним без да сме редактирали postinst-скрипта, ще получим пак същия неуспешен резултат, за това го правим след промени в него. Изпълняваме го и вече няма кое да спре завършването на скрипта scrollkeeper.postinst, оттам dpkg(8) и apt-get(8) завършват успешно работа и са разблокирани за по-нататъчни процедури. Започваме да търсим проблема на самия скрипт scrollkeeper-rebuilddb(8), разглеждайки кода му и стартирайки го с разни аргументи, като може дори да се наложи да направите промени и в самия него, след което пак да откоментираме достъпа до него от scrollkeeper.postinst и тестваме как ще работи той, например с:
# dpkg-reconfigure skrollkeeper
И така, докато постигнем някакъв по-задоволителен резултат. Това не сте длъжни да го правите, но за спорта си заслужава. След това, ако имате желание, можете да дръпнете debian source package и да внесете съответните подобрения, да ги предложите на maintainer-а на пакета, или просто да регистрирате бъг срещу този пакет от дадено ниво (вкл. и wishlist) на http://bugs.debian.org, ако вече това не е направено, разбира се.
В случая е даден прост пример, но можете да се сблъскате с истински предизвикателства и след като разблокирате (освободите) dpkg(8) и apt-get(8), от ход да потърсите и цялостно решение. Такива preinst-, postinst-, prerm-, postrm- скриптове, разбира се, ще намерите за всеки debian binary package, също така и в debian source package, от който е получен, както и в /var/lib/dpkg/info/пакет.скрипт.
Аналогично, вместо apt-get(8) и dpkg(8) да изчакват скриптовете, които не са си свършили работата по някаква причина, може направо да връщат грешка, при което да получите нещо от вида на:
apt-get remove xscreensaver .. .. .. .. .. .. .. .. .. .. dpkg: error processing xscreensaver (--remove): subprocess post-removal script returned error exit status 127 Errors were encountered while processing: xscreensaver
Процедурата е напълно аналогична на горeописаната, само че сега скриптовете направо приключват работа и уведомяват dpkg(8), че излизат с даден статус. В този пример очевидно трябва да се разправим със скрипта /var/lib/dpkg/info/xscreensaver.postrm, така че той да приключва работата си успешно. След което регистрираме това, изпълнявайки:
# dpkg-reconfigure xscreensaver