Re: [devel] [#202589] EPERM (try 2) bootloader-utils.git=0.5.0-alt1

[Paul Wolneykien <manowar@altlinux.org>]

23.03.2018 17:24, Mikhail Efremov пишет:
> On Fri, 23 Mar 2018 16:51:19 +0300 Mikhail Efremov wrote:
>> On Fri, 23 Mar 2018 15:11:13 +0300 Paul Wolneykien wrote:
>>> 23.03.2018 07:52, Alexey V. Vissarionov пишет:  
>>>> On 2018-03-23 02:03:27 +0300, Paul Wolneykien wrote:
>>>>     
>>>>  >> Вообще хорошо бы досмотреть собранное в пропавшем уже
>>>>  >> http://webery.altlinux.org/task/198627 (а ещё лучше со
>>>>  >> смерженным bootloader-utils.git)    
>>>>  > Ок, я смержу.    
>>>>
>>>> С утра пораньше прочитал это, как будто ты смердишь. Сильно
>>>> удивился, прочитал еще пару раз - дошло. Но как-то совсем уж
>>>> http://bash.im/quote/449514 получается...    
>>>
>>>   Тщательно вымылся (= совершил ритуальное омовение) и сделал мерж на
>>> свежую голову:
>>>
>>>
>>> http://git.altlinux.org/people/manowar/packages/bootloader-utils.git?p=bootloader-utils.git;a=shortlog;h=refs/heads/master
>>>
>>>   Выбор ядра по умолчанию пришлось обернуть в функцию вместо прибитого
>>> гвоздями `readlink /boot/vmlinuz`. Обработка каждого нового файла
>>> начинается с того, что VMLINUZ_PREFIX возвращается в исходное значение.
>>>
>>>   Если всё устраивает, то как удобнее: pull или новое задание и approve?  
>>
>> Я пора бегло взглянул, постараюсь еще посмотреть позже.
> 
> Посмотрел kernel.filetrigger:
> 1. SHARFILE нигде не определяется
> 2. Игры с переопределением VMLINUZ_PREFIX - это что-то ужасное.

  А почему, кстати? Глобальные переменные даже в C иногда используют, не
говоря уже о шелле. Разве что название можно дать более нейтральное —
например, KERNEL_PREFIX.

>    Раз теперь префиксы могут быть разные, то надо обернуть все
>    использования в функции и передавать значение префикса как аргумент,
>    например.
> 
>> Я, конечно, предпочел бы rebase без тегов/изменений в спеке
>> вместо merge, а то тяжело смотреть. Но это несколько больше работы,
>> ладно.
>> Пока у меня 2 вопроса:
>> Как commit message 'Seems to work' отражает сделанные в этом коммите
>> изменения?
>> Почему это все еще версия 0.5.1, а не 0.6 или, учитывая объем
>> изменений, даже 1.0.0?
>>
> 
> 
>