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

03.08.2018 18:36, Anton Farygin пишет:
> 03.08.2018 18:26, Aleksei Nikiforov пишет:
>>
>>
>> 03.08.2018 18:23, Dmitry V. Levin пишет:
>>> On Fri, Aug 03, 2018 at 06:20:28PM +0300, Aleksei Nikiforov wrote:
>>>> 03.08.2018 18:16, Dmitry V. Levin пишет:
>>>>> On Fri, Aug 03, 2018 at 06:05:17PM +0300, Aleksei Nikiforov wrote:
>>>>>> 03.08.2018 17:51, Dmitry V. Levin пишет:
>>>>>>> On Fri, Aug 03, 2018 at 11:58:50AM +0300, Dmitry V. Levin wrote:
>>>>>>>> On Thu, Aug 02, 2018 at 10:19:26PM +0300, Alexey Tourbin wrote:
>>>>>>>>> 2018-08-02 11:38 GMT+03:00 Aleksei Nikiforov 
>>>>>>>>> <darktemplar на altlinux.org>:
>>>>>>>>>> Я попробовал собрать bash3 и bash4 таким образом, с отдельными 
>>>>>>>>>> пакетами sh и
>>>>>>>>>> bash с симлинками и зависимостями на последнюю версию sh4 и bash4
>>>>>>>>>> соответственно.
>>>>>>>>>>
>>>>>>>>>> Проблема при такой сборке возникает с плагинами bash. Сейчас 
>>>>>>>>>> плагины для
>>>>>>>>>> bash3 лежат в /usr/lib/bash. Плагины bash4 лучше держать 
>>>>>>>>>> отдельно - их
>>>>>>>>>> больше по сравнению с bash3, да и совместимость не 
>>>>>>>>>> гарантированна. То, что
>>>>>>>>>> собранный для bash3 пакет bash-builtin-lockf работает с bash4 
>>>>>>>>>> скорее стоит
>>>>>>>>>> считать удачей и не рассчитывать на такое поведение, особенно 
>>>>>>>>>> при обновлении
>>>>>>>>>> до следующих версий bash.
>>>>>>>>>
>>>>>>>>> От добра добра не ищут, то есть не надо разделять 
>>>>>>>>> /usr/lib/bash, если
>>>>>>>>> и с ним все работает. Для bash3 все равно только один плагин, и 
>>>>>>>>> новых
>>>>>>>>> не будет.  И вообще проблема в миграции скриптов.
>>>>>>>>
>>>>>>>> Я бы тоже с плагинами не заморачивался.  Пусть все пакеты со 
>>>>>>>> сторонними
>>>>>>>> плагинами используют каталог /usr/lib/bash/.
>>>>>>>
>>>>>>> Давайте сделаем так:
>>>>>>> - плагины, собираемые в составе bash, упаковываются в 
>>>>>>> /usr/lib/bashN/;
>>>>>>> - сторонние плагины упаковываются в /usr/lib/bash/.
>>>>>>
>>>>>> А почему бы не сделать следующим образом?
>>>>>> - плагины для текущей версии баш в /usr/lib/bash/
>>>>>> - плагины для других версий баш в /usr/lib/bashN/
>>>>>>
>>>>>> В таком случае, если нужны сторонные плагины для нескольких версий 
>>>>>> bash,
>>>>>> их можно положить в соседние директории.
>>>>>
>>>>> Поскольку, в отличие от скриптов, плагины для bash - явление 
>>>>> чрезвычайно
>>>>> редкое, то держать в репозитории плагины для версии bash, отличной от
>>>>> текущей, я просто не вижу смысла.  Тем более что путь к плагину всё 
>>>>> равно
>>>>> указывается в скиптах явно.
>>>>
>>>> Тогда можно их не собирать для другой версии bash. В таком сценарии оба
>>>> сетапа равнозначны. Вопрос в том, а есть ли смысл раздельно держать
>>>> внутренние и сторонние плагины для bash?
>>>
>>> Думаю что имеет: у внутренних плагинов связывание с конкретной версией
>>> bash может быть довольно сильное, их точно следует держать в разных
>>> местах, зависящих от версии bash.
>>>
>>
>> В сторонних точно также может. В данном случае с bash-builtin-lockf, 
>> похоже, проблем нет, но это не значит, что теоретически с другой 
>> версией bash всё также гладко будет. 
> Может быть, всё таки всегда класть плагины bash в свои места, а в 
> bash-defaults  переключать симлинк /usr/lib/bash на самый последний ?

Я уже пытался сделать такой сетап. Проблема с миграцией существующей 
директории /usr/lib/bash на соответствующий симлинк. Если кто-то знает 
как это сделать с текущей версией rpm из Sisyphus, то можно доделать 
такой сетап.