до создания симлинков проверить

А это да, верно!

[ -r blah/*.so.* ] || false && ...

Если библиотеки не создались по причине ошибок при сборке, то должно упасть на стадии make. Однако, если же в новой версии ПО разработчики решили, что они (библиотеки) создаются не на старом месте, то можно до создания симлинков проверить, а есть ли цели?, и упасть при их отсутствии.

PS. Тема имеет контекстом разработку сценария сборки пакета для Slackware (.SlackBuild), который (контекст) относится к работе сопровождающего сторонних пакетов (maintaining) и не относится к собственно использованию ОС.

#!/bin/bash
PRGNAM=some
OUTPUT=/tmp
set -e
trap 'echo "$0 FAILED at line $LINENO!" | tee ${OUTPUT}/error-${PRGNAM}.log' ERR

false
echo "Недостижимый код."

Строка 4 указывает падать, если вызванная команда вернула ненулевой результат.
Строка 5 устанавливает ловушку на ошибку (ERR) с действием вывести (echo) сообщение об ошибке <имя сценария> ($0) FAILED at line <номер строки> ($LINENO), продублировав (tee) эту же строку в файл /tmp/error-some.log
Строка 7 содержит вызов false, которая всегда возвращает ненулевой код. Это запускает механизм выхода по ошибке. Строки ниже 7-й не исполняются.
Итого: ошибка приводит к падению и предотвращению выполнения команд, следующих за ошибочной.

Advanced scripting Bash guide

Спасибо, как-то на досуге читал. Только это ответ не на мой вопрос.

Теперь скажите нам всем

См. man bash, "Advanced scripting Bash guide".
Могу поцитировать из. Дорого.

Как это?

Теперь скажите нам всем, что сделано данным скриптом и как это корреспондирует с

если таковой возможности не предоставилось?

Как это? Скажите ж скорее, Карл!!!

PRGNAM=something
OUTPUT=/tmp
...
set -e
trap 'echo "$0 FAILED on line $LINENO!" | tee ${OUTPUT}/${PRGNAM}_err.log' ERR;
...
make    # если не собрались библиотеки, то упали тут

# перестраховка: переложили в новой версии библиотеки невесть куда?
[ -r blah/*.so.* ] || exit 1 && \
for F in blah/*.so.*; do 
    ln -s ...
done

орошей практикой является упасть по ошибке ДО того, как сценарий пойдет вразнос.

Совершенно согласен. Но если таковой возможности не предоставилось? Править руками конфиг как всегда, что я не упомянул за полной очевидностью.

То, куда будет добавлен код создания симлинков (в конец или в начало doinst.sh) зависит от отсутствия или наличия ключика  -p или его "длинного" собрата --prepend в вызове makepkg.

если в doinst.sh после вызова makepkg появились маски (wildcards) -- это значит они же имелись в симлинках в имени цели (target). Наличие в живых симлинках масок говорит о кривом как турецкая сабля коде создания таких симлинков. Хорошей практикой является упасть по ошибке ДО того, как сценарий пойдет вразнос. Кривость в следующем:

$ ls bla.so.*
ls: cannot access 'bla.so.*': No such file or directory

$ ln -s bla.so.* bla.so

$ ls -l bla.so
... bla.so -> bla.so.*   ' угу теперь символ "*" является частью имени цели (target) символьной ссылки

PS. Более подробное обсуждение там: http://www.slackware.ru/forum/viewtopic … amp;t=1915

# cat pkglist | xargs installpkg

Но тема была несколько о другой проблеме.
stranger,
Будучи не в теме -- советую просто пройти мимо, а не разводить флуд.

есть какие механизмы?

Да. Текстовый редактор.

имеется "стандартненький" такой пользовательский doinst.sh (кот. заготовкой лежит рядом со slackBuild-ом)

#
# ldconfig
#
if [ -x sbin/ldconfig ]; then
chroot . /sbin/ldconfig 2> /dev/null
fi

#
# Update the desktop database:
#
if [ -x usr/bin/update-desktop-database ]; then
chroot . /usr/bin/update-desktop-database usr/share/applications > /dev/null 2>&1
fi

#
# Update hicolor theme cache:
#
if [ -d usr/share/icons/hicolor        ]; then
if [ -x /usr/bin/gtk-update-icon-cache ]; then
  chroot . /usr/bin/gtk-update-icon-cache -f -t usr/share/icons/hicolor 1> /dev/null 2> /dev/null
fi
fi

#
# Update the mime database:
#
if [ -x usr/bin/update-mime-database ]; then
chroot . /usr/bin/update-mime-database usr/share/mime >/dev/null 2>&1
fi

по ходу в slackBuild-e делаются к.л. манипуляции, в результате makepkg формирует doinst.sh с содержанием

#
# ldconfig
#
if [ -x sbin/ldconfig ]; then
chroot . /sbin/ldconfig 2> /dev/null
fi

#
# Update the desktop database:
#
if [ -x usr/bin/update-desktop-database ]; then
chroot . /usr/bin/update-desktop-database usr/share/applications > /dev/null 2>&1
fi

#
# Update hicolor theme cache:
#
if [ -d usr/share/icons/hicolor        ]; then
if [ -x /usr/bin/gtk-update-icon-cache ]; then
  chroot . /usr/bin/gtk-update-icon-cache -f -t usr/share/icons/hicolor 1> /dev/null 2> /dev/null
fi
fi

#
# Update the mime database:
#
if [ -x usr/bin/update-mime-database ]; then
chroot . /usr/bin/update-mime-database usr/share/mime >/dev/null 2>&1
fi

#
# далее то, что навертели в slackBuild
#

( cd usr/bin ; rm -rf uic3-qt4 )
( cd usr/bin ; ln -sf /usr/lib64/qt-4.8.7/bin/uic3 uic3-qt4 )
( cd usr/bin ; rm -rf xmlpatternsvalidator-qt4 )
( cd usr/bin ; ln -sf /usr/lib64/qt-4.8.7/bin/xmlpatternsvalidator xmlpatternsvalidator-qt4 )
( cd usr/bin ; rm -rf qttracereplay-qt4 )
( cd usr/bin ; ln -sf /usr/lib64/qt-4.8.7/bin/qttracereplay qttracereplay-qt4 )
( cd usr/bin ; rm -rf uic-qt4 )
... бла бла бла

но, по идее "верхнюю часть, т.е. то, что было в пользовательском doinst.sh - надо бы вставить последней частью

вопрос: как это сделать, есть какие механизмы?

вводная:

1. идет сборка большого списка пакетов (и установка в систему)
2. пакеты складируются в свой подкаталог (типа $PKG)

пока идет процесс "сборка и сопутствующая установка" - все нормально (никаких казусов)

проблема - установка "на конечной" машине

обычная установка/обновление ВСЕГО этого зоопарка обычно у слакварщиков делается что-то типа (ну или подобное)

sudo /sbin/upgradepkg --reinstall --install-new $PKG/*.t?z
sudo /sbin/upgradepkg             --install-new $PKG/*.t?z

или что-то такое (взято как пример)

#!/bin/sh
for dir in a ap d e f k kde l n t tcl x xap y ; do
( cd $dir ; upgradepkg --install-new *.tgz )
done 

есть пакет, который ставится первым (или около того) !!! НО !!! в списке, при использовании шаблона "*.t?z" он будет в конце, и, соотв. ставиться/обновляться он будет позже...

далее код и описание относительно этого пакета

код slackBuild-а (код ПРИМЕРНЫЙ, дающий примерное представление)

mkdir -p LIB; cd LIB
for FILE in lib$x/*.so* ; do
ln -sf      lib$x/$(basename $FILE) .

дает код doinst.sh в пакете (код, так же, ПРИМЕРНЫЙ)

( cd LIB ; rm -rf *.so*             )
( cd LIB ; ln -sf lib$x/*.so* *.so* )

если пакеты буду ставиться НЕ ПО СПИСКУ, то данный пакет, устанавливаясь позже "все прочих" - просто напросто нахрен удалит ВСЁ из каталога LIB, уже установленных до этого файлов

итак:
можно разбить на группы и ставить последовательно, как тут

#!/bin/sh
for dir in a ap d e f k kde l n t tcl x xap y ; do
( cd $dir ; upgradepkg --install-new *.tgz )
done 

но мне удобно хранить все в одном каталоге
пока решаю обычным списком и скриптом, который ставит пакеты в нужной последовательности

вопрос:
- кто как решает данную проблему?
- проблема ли эта?!
- свои мысли по этому поводу
- только станд. команды (installpkg, upgradepkg, removepkg)

можно ключ. словами, ссылками

спасибо