Summary: | /etc/sysconfig/installkernel misplacement | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Vitaly Kuznetsov <vitty> |
Component: | bootloader-utils | Assignee: | placeholder <placeholder> |
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
Severity: | normal | ||
Priority: | P3 | CC: | at, boyarsh, glebfm, kas, ldv, placeholder, rider, sem, slazav, vitty, vt |
Version: | unstable | ||
Hardware: | all | ||
OS: | Linux | ||
Bug Depends on: | |||
Bug Blocks: | 24709 |
Description
Vitaly Kuznetsov
2010-12-07 19:34:53 MSK
Чем существующая поддержка 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. (In reply to comment #13) > Пока-что я вижу в новой версии bootloader-utils возможность с помощью отдельной > опции вернуть привычное поведение, вместо того, что бы отдельной опцией > включить новое. Новые опции не имеют прямого отношения к "привычному поведению", они реализуют новый, доселе не существовавший функционал. (In reply to comment #20) > Добавил. Спасибо, конфиг теперь в правильном месте. |