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

[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.

Первые два - внутренние разработки, с которыми особых проблем не
предвидится. Третий - думаю, истравить не особо сложно, а там и в
апстрим пропихнуть.

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


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net