[решено] Работа с rpm пакетами (Ликбез)

[lxa85]

Здравствуйте.
Работа с rpm пакетами доставляет боль.
С одной стороны - от них можно уйти заменив человеческими bash скрпитами, с другой наследие дистрибутива и требования заказчика.
Короче не отвертеться, как бы не были они мне противны.
Тк. зло нельзя победить, надо сделать так, чтобы оно не доставляло столько проблем. Следовательно, придется учить, как с ним работать.
И вот тут мне нужна помощь сообщества.
Какой "букварь", "курс" прочитать / изучить, чтобы от букв rpm не хотелось кого-нибудь придушить?
Какие задачи он решает, как его можно правильно настроить, чтобы проводилась "человеческая" (зачем то его придумали) установка пакетов ПО, согласно архитектур, и пр.

Короче - как с этой ... работать?
Причем задача стоит не только производить установку ПО в полу/автоматическом режиме, но начать со сборки из исходников.
Т.е. есть ПО, оно компилируется, пакуется в rpm, rpm копируется на целевую машину, и устанавливается.
Поэтому начиная от rpmbuild

Будете отправлять в google, делайте пожалуйста это с ссылкой на конкретный ресурс.

[Busla]

Работа с rpm пакетами доставляет боль. »
а что вы с ними делаете? :o

[MakaBooka]

Работа с rpm пакетами доставляет боль. »
Давайте начнём с конкретикию Что именно у вас не получается. Я не люблю RPM по своим причинам, но что есть боль и что именно вы имеете в виду - пока непонятно.

Следовательно, придется учить, как с ним работать. »
Простите, что увожу разговор в сторону, а что НЕ доставляет вам проблем? Ну просто для сравнения.

Какие задачи он решает »
Устанавливает софт в систему. С зависимостями.

ключи - в помощи rpm --help
Мурзилки по rpm в инете в обилии.

https://losst.ru/ustanovka-rpm-paketov-v-linux

Т.е. есть ПО, оно компилируется, пакуется в rpm, rpm копируется на целевую машину, и устанавливается. »
вот это уже конкретнее. У вас в техпроцессе пропущены шаги.

Т.е. есть ПО, оно компилируется, пакуется в rpm, rpm копируется в собственный репозиторий и оттуда устанавливается на целевые машины, которые этот репозиторий подключили.

Да вам нужен rpmbuild. Софт самописный?

[lxa85]

Начну в обратном порядке.
Софт самописный? »
Да. Самописный.
Т.е. есть ПО, оно компилируется, пакуется в rpm, rpm копируется в собственный репозиторий и оттуда устанавливается на целевые машины, которые этот репозиторий подключили. »
Да.
У вас в техпроцессе пропущены шаги. »
Вроде нет, но может за мелкими деталями. Прошу уточнить.
Простите, что увожу разговор в сторону, а что НЕ доставляет вам проблем? Ну просто для сравнения. »
Для сравнения мне не доставляет проблем bash скрипты в разработке которых я принимал участие. Работу которых я знаю
есть боль и что именно вы имеете в виду »
Скорее всего боль в том, что есть наследие скриптов, и остальные разработчики "свято в них верят". (может разная "культура использования" может еще что)
Мне доставляет боль криво написанные скрипты установки, которые трут все что ни попадя ничего при этом ни спрося. (т.е. может дело и не в rpm)
Мне НЕ доставляет боль положить скомпилированное ПО (пусть скриптами) в нужные папки по нужным путям (фактически исключив команды rpmbuild, rpm --install)
Т.к. разнообразием плафторм конечная система не отличается (строго один дистрибутив), то все танцы вокруг rpm мне не ясны.
Возможно есть в мире некоторая "человеческая практика" использования этого менеджера (что-то вроде best practics и подобных) или методические рекомендации.
Потому что сейчас это похоже на наследственную вакханалию, когда система выстраивалась методом "научного тыка", без документации и пр.
Опять же - может есть какая-нибудь наглядная ситуация, пример, в котором использование rpm дает ощутимый бонус.
А я этой ситуации не знаю, и поэтому воспринимаю rpm в штыки.

[Kent]

Какой "букварь", "курс" прочитать / изучить, чтобы от букв rpm не хотелось кого-нибудь придушить?
Какие задачи он решает, как его можно правильно настроить, чтобы проводилась "человеческая" (зачем то его придумали) установка пакетов ПО, согласно архитектур, и пр.
Короче - как с этой ... работать?
Причем задача стоит не только производить установку ПО в полу/автоматическом режиме, но начать со сборки из исходников. »
Для начала вот это почитайте (https://tigro.info/wp/?p=375) и это (http://red-hat-moscow-times.blogspot.com/2007/08/rpm.html).

Написано давно. Кое-что поменялось, но основы сохранились.

[Kent]

Собственно, сам 'rpm[8]' как менеджер пакетов, — это одно, а формат пакета "rpm" — это другое.

Если прочитали по ссылкам выше, то видите, что rpm-пакет это не просто набор файлов, а целая программа для установки (иногда удаления).
Вся "мощь" заложена в "*.spec", который определяет создание пакета. Возможности там почти безграничны. Используется и скриптовый язык иногда.

Реальный пример из дистрибутива openSUSE: librcc.spec (https://build.opensuse.org/package/view_file/devel:libraries:c_c++/librcc/librcc.spec?expand=1).
Другой пример, сложнее: bash.spec (https://build.opensuse.org/package/view_file/openSUSE:Factory/bash/bash.spec?expand=1)

А вот что показывает команда
rpm -q --scripts -p "crossover-14.0.3-1.rpm"
preinstall scriptlet (using /bin/sh):
#------------------------------------------------------------------------------
# Pre install script
#------------------------------------------------------------------------------
set -e

# Setup logging
if [ -n "$CX_LOG" ]
then
[ "$CX_LOG" = "-" ] || exec 2>>"$CX_LOG"
echo >&2
echo "***** `date`" >&2
echo "Starting: $0 $@" >&2
set -x
fi

if [ -z "$RPM_INSTALL_PREFIX" ]
then
RPM_INSTALL_PREFIX=/opt
fi
CX_ROOT="$RPM_INSTALL_PREFIX/cxoffice"
export CX_ROOT

cxgettext()
{
if [ -x "$CX_ROOT/bin/cxgettext" ] && "$CX_ROOT/bin/cxgettext" "$@"
then
return
fi
echo "$@"
}

report_error()
{
if [ -n "$DISPLAY" ]
then
cxmessage="$CX_ROOT/bin/cxmessage"
if [ -z "$CX_ROOT" -o ! -f "$cxmessage" -o ! -x "$cxmessage" ]
then
cxmessage="xmessage"
fi
"$cxmessage" \
-title "Unable to install" \
-buttons "Abort" \
-default "Abort" \
"$@" &
fi
echo "$@" >&2
}

# Keep the check for Loki's .manifest directory to handle upgrades from
# pre-10.0 versions.
if [ -d "$CX_ROOT/.manifest" -o -d "$CX_ROOT/.mojosetup" ]
then
msg=`cxgettext "This RPM package cannot be installed on top of a Loki or MojoSetup package."`
report_error "$msg"
exit 1
fi

# If this package is replacing a different package (e.g. a regular package
# replacing a demo), then "$1" will still be 1! So to correctly handle this
# case we need to check if another package provides cxoffice5 already.
# A further issue is that with some rpm versions, the "no package provides
# xxx" message may be printed to stdout so that 'wc -w' may return either 0
# or more than 1.
# Furthermore we still have to check "$1" to handle upgrades from very old
# packages that don't provide cxoffice5.
packages=`rpm -q --whatprovides cxoffice5 2>/dev/null | wc -w`
if [ "$1" != "1" -o "$packages" -eq 1 ]
then
mode="upgrade"
else
mode="install"
fi

if [ "$mode" = "install" ]
then
if [ -z "$CX_PRODUCT_ID" ]
then
CX_PRODUCT_ID="cxoffice"
fi
elif [ -f "$CX_ROOT/.productid" ]
then
CX_PRODUCT_ID=`cat "$CX_ROOT/.productid"`
else
CX_PRODUCT_ID="cxoffice"
fi
productid="$CX_PRODUCT_ID"


# This script expects CX_ROOT, productid and mode to be set

# Validate the productid
echo "$productid" | LC_ALL=C egrep '^[a-zA-Z0-9_][a-zA-Z0-9_][a-zA-Z0-9_][a-zA-Z0-9_][a-zA-Z0-9_]*$' >/dev/null
if [ $? -ne 0 ]
then
echo "The product id '$productid' is not valid" >&2
exit 1
fi

if [ "$mode" = "upgrade" ]
then
if [ -f "$CX_ROOT/.productid" ]
then
old_productid=`cat "$CX_ROOT/.productid"`
else
old_productid="cxoffice"
fi
if [ "$productid" != "$old_productid" ]
then
echo "An upgrade cannot change the product id" >&2
exit 1
fi
fi

# Remove generated files that old packages incorrectly leave around
rm -f "$CX_ROOT"/support/icons/*.png


# RPM only deletes this file after the postinstall script is run!
rm -f "$CX_ROOT/lib/nptl"/libwine.so*
postinstall scriptlet (using /bin/sh):
#------------------------------------------------------------------------------
# Post install script
#------------------------------------------------------------------------------
set -e

# Setup logging
if [ -n "$CX_LOG" ]
then
[ "$CX_LOG" = "-" ] || exec 2>>"$CX_LOG"
echo >&2
echo "***** `date`" >&2
echo "Starting: $0 $@" >&2
set -x
fi

if [ -z "$RPM_INSTALL_PREFIX" ]
then
RPM_INSTALL_PREFIX=/opt
fi
CX_ROOT="$RPM_INSTALL_PREFIX/cxoffice"
export CX_ROOT
package="rpm:crossover"

# See the %pre comment.
# Note that in this script we know that at least one package provides
# cxoffice5.
packages=`rpm -q --whatprovides cxoffice5 2>/dev/null | wc -w`
if [ "$1" != "1" -o "$packages" -gt 1 ]
then
mode="upgrade"
else
mode="install"
fi
oldver=""

if [ "$mode" = "install" ]
then
if [ -z "$CX_PRODUCT_ID" ]
then
CX_PRODUCT_ID="cxoffice"
fi
elif [ -f "$CX_ROOT/.productid" ]
then
CX_PRODUCT_ID=`cat "$CX_ROOT/.productid"`
else
CX_PRODUCT_ID="cxoffice"
fi
productid="$CX_PRODUCT_ID"

# This script expects package, CX_ROOT, productid, mode and oldver to be set


builtin_product_id="cxoffice"
if [ "$mode" = "install" ]
then
if [ "$productid" != "$builtin_product_id" ]
then
echo "$productid" >"$CX_ROOT/.productid"
else
rm -f "$CX_ROOT/.productid"
fi
fi

uid=`perl -e 'print $>'`

unset HOME

# These files are no longer needed (were used by version 4.x)
if [ "$uid" = "0" -a -f "/sbin/conf.d/SuSEconfig.zz$productid-vfolders" ]
then
rm -f "/sbin/conf.d/SuSEconfig.zz$productid-vfolders"
fi
rm -f "$CX_ROOT/lib/xml/libperl.so.5.8"

# Icons have moved to share/icons
rm -f "$CX_ROOT"/support/*.png

# We don't need the 2007 DST bottle hook anymore
rm -f "$CX_ROOT"/support/scripts.d/??.dst2007patch
rmdir "$CX_ROOT"/support/scripts.d 2>/dev/null || true

# Try to set up the security context if possible (especially for Fedora).
# Do so before potentially trying to upgrade bottles.
setup_selinux()
{
# Note that this may or may not work depending on obscure system settings.
# So try chcon on the landmark file and don't abort if that fails.
if chcon system_u:object_r:bin_t:s0 "$CX_ROOT"/bin/cxmenu
then
( cd "$CX_ROOT"/bin && find * -type d -prune -o -type f \
-exec chcon system_u:object_r:bin_t:s0 {} \; )
( cd "$CX_ROOT"/lib && find * -type d -prune -o -type f \
-exec chcon system_u:object_r:lib_t:s0 {} \; )
chcon system_u:object_r:wine_exec_t:s0 "$CX_ROOT"/bin/wine-preloader "$CX_ROOT"/bin/wineloader
if chcon system_u:object_r:textrel_shlib_t:s0 "$CX_ROOT"/lib/wine/ntdll.dll.so
then
setype="textrel_shlib_t"
else
setype="lib_t"
fi
( cd "$CX_ROOT"/lib/wine && find * -type d -prune -o -type f \
-exec chcon system_u:object_r:$setype:s0 {} \; )
fi
}
if [ -z "$CX_LOG" ]
then
setup_selinux 2>/dev/null
else
setup_selinux
fi


# Create or upgrade the configuration file and more
if [ -f "$CX_ROOT/.uninstalled" ]
then
rm -f "$CX_ROOT/.uninstalled"
install_bottles="--install-bottles"
else
install_bottles=""
fi
"$CX_ROOT/lib/cxupgrade" --package "$package" --productid "$productid" --old-version "$oldver" $install_bottles
"$CX_ROOT/bin/cxtie" --register

if [ "$mode" = "install" -a "$uid" = "0" ]
then
chmod 0644 "$CX_ROOT/etc/$productid.conf"
fi

exit 0
preuninstall scriptlet (using /bin/sh):
#------------------------------------------------------------------------------
# Pre uninstallation script
#------------------------------------------------------------------------------
set -e

# Setup logging
if [ -n "$CX_LOG" ]
then
[ "$CX_LOG" = "-" ] || exec 2>>"$CX_LOG"
echo >&2
echo "***** `date`" >&2
echo "Starting: $0 $@" >&2
set -x
fi

# See the %pre comment.
# Note that in this script we know that at least one package still provides
# cxoffice5.
packages=`rpm -q --whatprovides cxoffice5 2>/dev/null | wc -w`
if [ "$1" != "0" -o "$packages" -gt 1 ]
then
# This package is being upgraded or replaced by another
exit 0
fi

if [ -z "$RPM_INSTALL_PREFIX" ]
then
RPM_INSTALL_PREFIX=/opt
fi
CX_ROOT="$RPM_INSTALL_PREFIX/cxoffice"
export CX_ROOT

if [ -f "$CX_ROOT/.productid" ]
then
productid=`cat "$CX_ROOT/.productid"`
else
productid="cxoffice"
fi

[ -n "$CX_PURGE" ] || CX_PURGE="desktopdata"
export CX_PURGE


# This script expects CX_ROOT and productid to be set
# Note: this script may also be called in case the installation is aborted
builtin_product_id="cxoffice"

if [ -z "$CX_PURGE" ]
then
CX_PURGE="all"
fi

if [ "$CX_PURGE" = "desktopdata" -o "$CX_PURGE" = "all" ]
then
"$CX_ROOT/bin/cxtie" --unregister
scope="managed"
if [ -x "$CX_ROOT/bin/cxmenu" ]
then
"$CX_ROOT/bin/cxmenu" --removeall --pattern "$productid-" --scope $scope --ignorelist ""
fi
if [ -x "$CX_ROOT/bin/cxassoc" ]
then
"$CX_ROOT/bin/cxassoc" --removeall --pattern "$productid-" --scope $scope --ignorelist ""
fi
if [ -x "$CX_ROOT/bin/cxnsplugin" ]
then
"$CX_ROOT/bin/cxnsplugin" --removeall --pattern "$productid-" --scope $scope
fi
rm -f "$CX_ROOT"/share/icons/*.png
fi

rm -f "$CX_ROOT/lib/python"/*.pyc
rm -f "$CX_ROOT/lib/wine/winewrapper.exe.so.bak"

# We must delete any file generated at runtime before 'rpm -e'
# tries to delete the installed files and directories.
# This script expects CX_ROOT and productid to be set

if [ -z "$CX_PURGE" ]
then
CX_PURGE="all"
fi

if [ "$CX_PURGE" = "desktopdata" -o "$CX_PURGE" = "all" ]
then
rm -rf "$CX_ROOT"/support/desktopdata
fi

if [ "$CX_PURGE" = "all" ]
then
rm -f "$CX_ROOT/etc/$productid".conf*
rm -f "$CX_ROOT/etc/license.txt" "$CX_ROOT/etc/license.sig"
rm -f "$CX_ROOT"/support/default
rm -rf "$CX_ROOT"/support/installers
rm -f "$CX_ROOT"/.uninstalled

# Delete bottles.
ls -d "$CX_ROOT"/support/*/cxbottle.conf 2>/dev/null | while read bottlefile
do
dir=`dirname "$bottlefile"`
rm -rf "$dir"
done

rmdir "$CX_ROOT"/support 2>/dev/null || true
rm -f "$CX_ROOT/.productid"
elif [ -d "$CX_ROOT" ]
then
touch "$CX_ROOT/.uninstalled"
fi

exit 0
postuninstall scriptlet (using /bin/sh):
#------------------------------------------------------------------------------
# Post uninstallation script
#------------------------------------------------------------------------------
Сторонний rpm-пакет. Не приветствуются такие скриптовые манипуляции.

Спрашивайте. По возможности, отвечу. 10 лет для openSUSE rpm-пакеты собираю.