SuSE 9.2 - компиляция ядра: начало 0

А нафига вам центр управления?

Скачиваете исходники, делаете make config, make rpm

потом устанавливаете rpm с ядром и все.

Хм.. а новая rpm нормально будет уживаться с остальными, не может получится следующее — при устновке очередной секурной заплатки Yast или apt ругнётся, чт мол.. фигня какая то а не rpm ? .. (сам не пробовал не знаю) … или же механизм раблты rpm настолько гибкий, что позволяет проводить такие фокусы?

vmbeast
Хм.. а новая rpm нормально будет уживаться с остальными, не может получится следующее — при устновке очередной секурной заплатки Yast или apt ругнётся, чт мол.. фигня какая то а не rpm ? .. (сам не пробовал не знаю) …

С чего бы ему ругаться? Ты ж ставишь другие пакеты не из дистрибутива, и никто на них не ругается.

vmbeast
или же механизм раблты rpm настолько гибкий, что позволяет проводить такие фокусы?

Какие фокусы? Устанавливать новые RPM-пакеты? Ну да, позволяет ;).

Еще бы знать, что на вопросы отвечать… В половине случаев не знаю, что это такое.

airfly
Еще бы знать, что на вопросы отвечать… В половине случаев не знаю, что это такое.

Думал, думал, прикидывал, и так и не понял…. О чём это ты?

С чего бы ему ругаться? Ты ж ставишь другие пакеты не из дистрибутива, и никто на них не ругается.

строго говоря, ответ не то, чтобы неверен… некорректен, скорее.

ведь в каждом дистрибутиве пакеты, относящиеся к ядру, собираются по определённой технологии, несколько отличной от того, что присутствует в Makefile дерева исходников ядра.

и, соответственно, дополнительные указания/зависимости/предоставления_функций, предусматривающиеся политикой дистрибутива, так же не учитываются.

поэтому — конфликт и может возникнуть, и может не возникнуть. тут как уж повезёт. ;)

Еще бы знать, что на вопросы отвечать… В половине случаев не знаю, что это такое.

Думал, думал, прикидывал, и так и не понял…. О чём это ты?

есть такое дичайшее подозрение, что это относится к вопросам, задаваемым при make config.

оргомное число вопросов, и, честно сказать, мне самому половина непонятна.. ;)

много лучше использовать make menuconfig, как несколько более вменяемую и более абстрагирующую от такого детального рассмотрения настроек ядра.

Или я потерял нить беседы, или одно из двух.. ;)

Genie
строго говоря, ответ не то, чтобы неверен… некорректен, скорее.

Или я потерял нить беседы, или одно из двух.. ;)

Genie
ведь в каждом дистрибутиве пакеты, относящиеся к ядру, собираются по определённой технологии, несколько отличной от того, что присутствует в Makefile дерева исходников ядра.

и, соответственно, дополнительные указания/зависимости/предоставления_функций, предусматривающиеся политикой дистрибутива, так же не учитываются.

После процесса сборки пакета «по определённой технологии, несколько отличной от того, что присутствует в Makefile дерева исходников ядра» мы получим самый обыкновенный RPM-пакет, который для rpm-менеджера будет таким же как и тысячи других. Я ответил на то, что при установке сего RPM-пакета ничего страшного и сверхъестесственного для rpm-менеджера не произойдёт (это к вопросу: «или же механизм раблты rpm настолько гибкий, что позволяет проводить такие фокусы?»).

Более того, что ты подразумеваешь под «сборкой пакета по определённой технологии, несколько отличной от того, что присутствует в Makefile дерева исходников ядра»? Оно что ли как-то иначе скомпилируется? ;)

Genie
поэтому — конфликт и может возникнуть, и может не возникнуть. тут как уж повезёт. ;)

Тут надо бы всё-таки уточнить у кого и с чем может возникнуть конфликт. Т.к. ни у Yast’а, о котором упомянул вопрошавший, ни у rpm-менеджера никаких конфликтов с RPM-пакетом возникнуть не должно.