Re: [devel] [#210757] EPERM (try 3) bash3.git=3.2.57-alt4 bash.git=4.4.23-alt1 bash-completion.git=2.8-alt1

[Aleksei Nikiforov <darktemplar@basealt.ru>]

02.08.2018 13:24, Alexey V. Vissarionov пишет:
> On 2018-08-02 12:08:13 +0300, Aleksei Nikiforov wrote:
> 
>   >>> Проблема при такой сборке возникает с плагинами bash. Сейчас
>   >>> плагины для bash3 лежат в /usr/lib/bash. Плагины bash4 лучше
>   >>> держать отдельно - их больше по сравнению с bash3, да и
>   >>> совместимость не гарантированна.
>   >> Они сами по себе, или могут приехать с каким-то сторонним
>   >> софтом?
>   > В bash3 таких встроенных плагинов нет, в bash4 - более десятка.
>   > Также есть внешние - это как минимум в пакетах bash-builtin-lockf
>   > и bashdb.
> 
> Ну, то есть, это все же самостоятельные пакеты (продолжение сабжа),
> а не куски какого-то софта, которому сабж просто нужен для работы.
> 
> Уже хорошо.
> 
>   >>> Если для совместимости с текущим сетапом использовать
>   >>> /usr/lib/bash для плагинов bash3, то плагины bash4 можно
>   >>> положить в /usr/lib/bash4, например.
>   >> Если они меж собой несовместимы - вплоть до %_libdir/%name-%version
>   > Надеюсь в репозитории не будет столько версий bash, чтобы
>   > потребовалось столько директорий с настолько подробным
>   > разделением по версиям. И таки не %_libdir, а скорее %_libexecdir.
> 
> Да пофигу...
> 
>   >>> Но тогда в некоторых пакетах для переезда на bash4 прийдётся
>   >>> явно менять захардкоженный путь до /usr/lib/bash/lockf
>   >> А много ли таких пакетов?
>   > Я нашёл пока что только 3: girar, hasher и gnupg2.
> 
> Первые два - внутренние разработки, с которыми особых проблем не
> предвидится. Третий - думаю, истравить не особо сложно, а там и в
> апстрим пропихнуть.
> 

Для gnupg2 это, похоже, тоже локальное изменение.

>   >>> либо скриптовать поведение по поиску пути до lockf в зависимости
>   >>> от версии bash,
>   >> И это правильное решение, так как для его реализации достаточно
>   >> одного файла /etc/profile.d/lockf.sh со строчкой export LOCKF=...
>   >>> Например, такой путь захардкожен в girar, hasher, gnupg2
>   >> Дык и добавить туда проверку $LOCKF
>   >> Определено - пользуем, нет - export LOCKF="/usr/lib/bash/lockf" и
>   >> опять же пользуем.
>   > Это не отменяет того факта, что нужно для таких пакетов добавлять
>   > зависимость на пакет, содержащий lockf для правильной версии bash
>   > помимо прочего.
> 
> Дык если оно используется - значит, нужна зависимость.
> К.О. спешит на помощь, ага.
> 

Да, зависимость нужна, но в зависимости от того, как упакованы такие 
плагины, возможно пакеты, зависящие от таких плагинов, с изменением 
версии bash нужно будет пересобирать просто для указания другой версии 
такого плагина, что мне собственно и не хотелось бы делать.

>   > Можно конечно lockf для всех версий bash в репозитории засунуть
>   > в 1 пакет, но такой подход мне не особо нравится.
> 
> Зачем? Пусть будут bash4-plugin-lockf и bash5-plugin-lockf, каждый
> в своем каталоге. А по файлу /etc/profile.d/lockf.sh у них будет
> банальнейший конфликт (что разумно, ибо смысла держать в системе
> более одной версии вообще никакого).
> 
> Или /etc/profile.d/bash4_lockf.sh и /etc/profile.d/bash5_lockf.sh
> с проверкой версии (если не та - просто вываливаемся безо всяких
> ошибок).
> 
> Вот, не поленился грепнуть `man bash`:
> 
>   BASH_VERSINFO
>    A readonly array variable whose members hold version information
>    for this instance of bash. The values assigned to the array
>    members are as follows:
>    BASH_VERSINFO[0]  The major version number (the release).
>    BASH_VERSINFO[1]  The minor version number (the version).
>    BASH_VERSINFO[2]  The patch level.
>    BASH_VERSINFO[3]  The build version.
>    BASH_VERSINFO[4]  The release status (e.g., beta1).
>    BASH_VERSINFO[5]  The value of MACHTYPE.
> 
>   BASH_VERSION
>    Expands to a string describing the version of this instance of
>    bash.
> 
> То есть, достаточно проверять `bash -c 'echo ${BASH_VERSINFO[0]}'`
> 
> 

Да, один из вариантов как такое можно было бы реализовать. Спасибо!