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

[Mikhail Efremov <sem@altlinux.org>]

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 - это что-то ужасное.
   Раз теперь префиксы могут быть разные, то надо обернуть все
   использования в функции и передавать значение префикса как аргумент,
   например.

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



-- 
WBR, Mikhail Efremov