По итогам обсуждения http://lists.altlinux.org/pipermail/sisyphus/2010-December/350814.html хочется добавить новые опции для installkernel. Предлагаю перенести /etc/sysconfig/installkernel из make-initrd в bootloader-utils. Это и логично, и удобно.
Чем существующая поддержка make-initrd не устраивает? http://git.altlinux.org/people/vitty/packages/bootloader-utils.git?p=bootloader-utils.git;a=blob;f=installkernel;h=9656e8d27e5068763b504c65e4e7f0beb265f755;hb=34179be0c86801a821db0152d8d3f8ceb81cfd2c#l84 как бы то ни было, эту багу нужно вешать на bootloader-utils.
В этой баге я предлагаю перенести файл /etc/sysconfig/installkernel в bootloader-utils из make-initrd т.к. это конфиг для скрипта installkernel, лежащего в bootloader-utils. Я его готов добавить в bootloader-utils, но мне нужно чтобы его удалили из make-initrd.
(In reply to comment #1) > Чем существующая поддержка make-initrd не устраивает? Не устраивает затруднительность добавлять фичи в installkernel, потому что сам installkernel и конфиг для него находятся в разных пакетах. При переносе конфига не забудьте добавить соответствующие conflicts в оба пакета.
Сейчас bootloader-utils не предоставляет /etc/sysconfig/installkernel. Что мешает добавить его как %config ?
(In reply to comment #4) > Сейчас bootloader-utils не предоставляет /etc/sysconfig/installkernel. Что > мешает добавить его как %config ? Если файл с одним именем и различным содержимым будет принадлежать двум разным пакетам, то случится конфликт, и атрибут %config(noreplace) не поможет избежать его.
Предлагаю собрать в сизиф следующее: http://git.altlinux.org/people/vitty/packages/?p=make-initrd.git;a=commitdiff;h=0b29bf053714b53d2b7cf2c244437b21647950cd http://git.altlinux.org/people/vitty/packages/?p=bootloader-utils.git;a=commitdiff;h=e2b7c677c1d870038d3e08cb0a73c5b6f47d2cd2
(В ответ на комментарий №5) > Если файл с одним именем и различным содержимым будет принадлежать двум разным > пакетам, то случится конфликт, и атрибут %config(noreplace) не поможет избежать > его. Хорошо. Расшарьте задание. Я добавлю make-initrd без этого конфига и с конфликтом на старую версию bootloader-utils.
> Хорошо. Расшарьте задание. > > Я добавлю make-initrd без этого конфига и с конфликтом на старую версию > bootloader-utils. task #34965 Стоит поставить не конфликт на старую, а Requires на новую (0.4.10-alt1)
Виталик, я же просил - не менять поведение по умолчанию. Вместо KEEPINITRD надо UPDATEINITRD, иначе будет поломано поведение на уже существующих системах сразу при обновлении. Т.е. - заменять INITRD только в случае его отсутствия.
(In reply to comment #9) > Виталик, я же просил - не менять поведение по умолчанию. > > Вместо KEEPINITRD надо UPDATEINITRD, иначе будет поломано поведение на уже > существующих системах сразу при обновлении. > > Т.е. - заменять INITRD только в случае его отсутствия. Антон, эти опции нужны для реализации фичи, сами по себе они поведение не меняют.
Я внимательно посмотрел изменения у тебя в git-е. http://git.altlinux.org/people/vitty/packages/?p=bootloader-utils.git;a=commitdiff;h=97d94975e4f79220ca110d3f2183f2a3c3717edc Расскажи, пожалуйста, какое будет умолчательное поведение без изменения существующего конфигурационного файла после окончательной реализации фичи ?
(In reply to comment #11) > Я внимательно посмотрел изменения у тебя в git-е. > http://git.altlinux.org/people/vitty/packages/?p=bootloader-utils.git;a=commitdiff;h=97d94975e4f79220ca110d3f2183f2a3c3717edc > > Расскажи, пожалуйста, какое будет умолчательное поведение без изменения > существующего конфигурационного файла после окончательной реализации фичи ? На реализованных фичах можно реализовать любое поведение, но давай не в этой баге (которая совсем о другом) это обсуждать.
Давай мы лучше не будем пытаться сделать такие фичи, от которых потом придётся долго и мучительно избавляться ? Тогда и обсуждать ничего не надо будет. Пока-что я вижу в новой версии bootloader-utils возможность с помощью отдельной опции вернуть привычное поведение, вместо того, что бы отдельной опцией включить новое. Если я не прав, то готов выслушать твои доводы, и нет смысла открывать для этого отдельную тему, мы уже достаточно обсудили в списке рассылки и так уже всё понятно.
Кстати, это: - add make-initrd dependency тоже довольно спорно. У меня есть по крайней мере одна система, на которой ядра с initrd от текущего сизифного make-initrd не загружаются. И, к сожалению, отлаживаться на ней не получится - надо что б работало, да и далеко она, а serial console на том сервере нет.
(In reply to comment #14) > Кстати, это: > - add make-initrd dependency > тоже довольно спорно. > > У меня есть по крайней мере одна система, на которой ядра с initrd от текущего > сизифного make-initrd не загружаются. По умолчанию Сизифный installkernel использует Сизифный make-initrd, логично?
(In reply to comment #13) > Если я не прав, то готов выслушать твои доводы, и нет смысла открывать для > этого отдельную тему, мы уже достаточно обсудили в списке рассылки и так уже > всё понятно. Здесь речь идет о переносе конфига из одного пакета в другой, все остальное это offtopic.
Дима, можно писать и говорить что угодно, но факт есть факт - принудительное обновление конфигурации на make-initrd может поломать старые системы. mkinitrd в сизифе, и он отлично работает несмотря ни на что :) А где это писать - не имеет значения, важно что б об этом не умалчивалось.
(In reply to comment #17) > Дима, можно писать и говорить что угодно, но факт есть факт - принудительное > обновление конфигурации на make-initrd может поломать старые системы. mkinitrd > в сизифе, и он отлично работает несмотря ни на что :) Да, может поломать. Надо еще протестировать обновление с локально модифицированным конфигом; мне кажется, что имеет смысл реализовать %triggerpostun для того, чтобы локальные изменения не потерялись.
на данном этапе лучше всего оставить умолчательное поведение старым, не забрасывая принудительно make-initrd в уже установленные системы. Добавить зависимость у bootloader-utils можно в любой момент. Как и попросить людей включить опцию в конфиге, если им захочется обновить initrd принудительно для всех старых ядер (которые в итоге всё равно должны будут удаляться, сохраняются они только для возможной загрузки в случае проблем). т.е. - конфиг лучше не трогать вообще, предложив умолчанием считать предыдущее поведение bootloader-utils.
(В ответ на комментарий №8) > task #34965 Добавил.
(In reply to comment #13) > Пока-что я вижу в новой версии bootloader-utils возможность с помощью отдельной > опции вернуть привычное поведение, вместо того, что бы отдельной опцией > включить новое. Новые опции не имеют прямого отношения к "привычному поведению", они реализуют новый, доселе не существовавший функционал.
(In reply to comment #20) > Добавил. Спасибо, конфиг теперь в правильном месте.
