24707 2010-12-07 19:34:53 +0300 /etc/sysconfig/installkernel misplacement 2010-12-08 01:09:47 +0300 1 1 4 Development Sisyphus bootloader-utils unstable all Linux CLOSED FIXED P3 normal --- 24709 1 vitty placeholder at boyarsh glebfm kas ldv placeholder rider sem slazav vitty vt qa-sisyphus oldest_to_newest 116086 0 vitty 2010-12-07 19:34:53 +0300 По итогам обсуждения http://lists.altlinux.org/pipermail/sisyphus/2010-December/350814.html хочется добавить новые опции для installkernel. Предлагаю перенести /etc/sysconfig/installkernel из make-initrd в bootloader-utils. Это и логично, и удобно. 116087 1 legion 2010-12-07 19:45:37 +0300 Чем существующая поддержка 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. 116088 2 vitty 2010-12-07 20:04:54 +0300 В этой баге я предлагаю перенести файл /etc/sysconfig/installkernel в bootloader-utils из make-initrd т.к. это конфиг для скрипта installkernel, лежащего в bootloader-utils. Я его готов добавить в bootloader-utils, но мне нужно чтобы его удалили из make-initrd. 116089 3 ldv 2010-12-07 20:09:58 +0300 (In reply to comment #1) > Чем существующая поддержка make-initrd не устраивает? Не устраивает затруднительность добавлять фичи в installkernel, потому что сам installkernel и конфиг для него находятся в разных пакетах. При переносе конфига не забудьте добавить соответствующие conflicts в оба пакета. 116090 4 legion 2010-12-07 20:18:45 +0300 Сейчас bootloader-utils не предоставляет /etc/sysconfig/installkernel. Что мешает добавить его как %config ? 116091 5 ldv 2010-12-07 20:24:14 +0300 (In reply to comment #4) > Сейчас bootloader-utils не предоставляет /etc/sysconfig/installkernel. Что > мешает добавить его как %config ? Если файл с одним именем и различным содержимым будет принадлежать двум разным пакетам, то случится конфликт, и атрибут %config(noreplace) не поможет избежать его. 116092 6 vitty 2010-12-07 20:29:52 +0300 Предлагаю собрать в сизиф следующее: 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 116093 7 legion 2010-12-07 20:31:17 +0300 (В ответ на комментарий №5) > Если файл с одним именем и различным содержимым будет принадлежать двум разным > пакетам, то случится конфликт, и атрибут %config(noreplace) не поможет избежать > его. Хорошо. Расшарьте задание. Я добавлю make-initrd без этого конфига и с конфликтом на старую версию bootloader-utils. 116094 8 vitty 2010-12-07 20:36:49 +0300 > Хорошо. Расшарьте задание. > > Я добавлю make-initrd без этого конфига и с конфликтом на старую версию > bootloader-utils. task #34965 Стоит поставить не конфликт на старую, а Requires на новую (0.4.10-alt1) 116095 9 rider 2010-12-07 20:38:59 +0300 Виталик, я же просил - не менять поведение по умолчанию. Вместо KEEPINITRD надо UPDATEINITRD, иначе будет поломано поведение на уже существующих системах сразу при обновлении. Т.е. - заменять INITRD только в случае его отсутствия. 116096 10 vitty 2010-12-07 20:41:10 +0300 (In reply to comment #9) > Виталик, я же просил - не менять поведение по умолчанию. > > Вместо KEEPINITRD надо UPDATEINITRD, иначе будет поломано поведение на уже > существующих системах сразу при обновлении. > > Т.е. - заменять INITRD только в случае его отсутствия. Антон, эти опции нужны для реализации фичи, сами по себе они поведение не меняют. 116097 11 rider 2010-12-07 20:43:59 +0300 Я внимательно посмотрел изменения у тебя в git-е. http://git.altlinux.org/people/vitty/packages/?p=bootloader-utils.git;a=commitdiff;h=97d94975e4f79220ca110d3f2183f2a3c3717edc Расскажи, пожалуйста, какое будет умолчательное поведение без изменения существующего конфигурационного файла после окончательной реализации фичи ? 116098 12 vitty 2010-12-07 20:47:30 +0300 (In reply to comment #11) > Я внимательно посмотрел изменения у тебя в git-е. > http://git.altlinux.org/people/vitty/packages/?p=bootloader-utils.git;a=commitdiff;h=97d94975e4f79220ca110d3f2183f2a3c3717edc > > Расскажи, пожалуйста, какое будет умолчательное поведение без изменения > существующего конфигурационного файла после окончательной реализации фичи ? На реализованных фичах можно реализовать любое поведение, но давай не в этой баге (которая совсем о другом) это обсуждать. 116099 13 rider 2010-12-07 20:51:24 +0300 Давай мы лучше не будем пытаться сделать такие фичи, от которых потом придётся долго и мучительно избавляться ? Тогда и обсуждать ничего не надо будет. Пока-что я вижу в новой версии bootloader-utils возможность с помощью отдельной опции вернуть привычное поведение, вместо того, что бы отдельной опцией включить новое. Если я не прав, то готов выслушать твои доводы, и нет смысла открывать для этого отдельную тему, мы уже достаточно обсудили в списке рассылки и так уже всё понятно. 116100 14 rider 2010-12-07 21:02:11 +0300 Кстати, это: - add make-initrd dependency тоже довольно спорно. У меня есть по крайней мере одна система, на которой ядра с initrd от текущего сизифного make-initrd не загружаются. И, к сожалению, отлаживаться на ней не получится - надо что б работало, да и далеко она, а serial console на том сервере нет. 116101 15 ldv 2010-12-07 21:13:36 +0300 (In reply to comment #14) > Кстати, это: > - add make-initrd dependency > тоже довольно спорно. > > У меня есть по крайней мере одна система, на которой ядра с initrd от текущего > сизифного make-initrd не загружаются. По умолчанию Сизифный installkernel использует Сизифный make-initrd, логично? 116102 16 ldv 2010-12-07 21:16:14 +0300 (In reply to comment #13) > Если я не прав, то готов выслушать твои доводы, и нет смысла открывать для > этого отдельную тему, мы уже достаточно обсудили в списке рассылки и так уже > всё понятно. Здесь речь идет о переносе конфига из одного пакета в другой, все остальное это offtopic. 116103 17 rider 2010-12-07 21:20:37 +0300 Дима, можно писать и говорить что угодно, но факт есть факт - принудительное обновление конфигурации на make-initrd может поломать старые системы. mkinitrd в сизифе, и он отлично работает несмотря ни на что :) А где это писать - не имеет значения, важно что б об этом не умалчивалось. 116104 18 ldv 2010-12-07 21:25:01 +0300 (In reply to comment #17) > Дима, можно писать и говорить что угодно, но факт есть факт - принудительное > обновление конфигурации на make-initrd может поломать старые системы. mkinitrd > в сизифе, и он отлично работает несмотря ни на что :) Да, может поломать. Надо еще протестировать обновление с локально модифицированным конфигом; мне кажется, что имеет смысл реализовать %triggerpostun для того, чтобы локальные изменения не потерялись. 116105 19 rider 2010-12-07 21:29:38 +0300 на данном этапе лучше всего оставить умолчательное поведение старым, не забрасывая принудительно make-initrd в уже установленные системы. Добавить зависимость у bootloader-utils можно в любой момент. Как и попросить людей включить опцию в конфиге, если им захочется обновить initrd принудительно для всех старых ядер (которые в итоге всё равно должны будут удаляться, сохраняются они только для возможной загрузки в случае проблем). т.е. - конфиг лучше не трогать вообще, предложив умолчанием считать предыдущее поведение bootloader-utils. 116110 20 legion 2010-12-07 22:12:54 +0300 (В ответ на комментарий №8) > task #34965 Добавил. 116127 21 vitty 2010-12-08 00:43:30 +0300 (In reply to comment #13) > Пока-что я вижу в новой версии bootloader-utils возможность с помощью отдельной > опции вернуть привычное поведение, вместо того, что бы отдельной опцией > включить новое. Новые опции не имеют прямого отношения к "привычному поведению", они реализуют новый, доселе не существовавший функционал. 116128 22 vitty 2010-12-08 00:55:34 +0300 (In reply to comment #20) > Добавил. Спасибо, конфиг теперь в правильном месте.