[d-kernel] Опять грабли с новой схемой сборки

[Michael Shigorin]

On Wed, Aug 13, 2003 at 04:25:00PM +0400, Anton Farygin wrote:
> >>Как пользователь должен обновлять пакеты с ядрами?
> >Возможно, для этого стоит сделать отдельную тулзень, которая
> >будет иметь достаточно специфический интеллект.
> Нет. Это не выход.

Я ж написал "возможно".  Не помню всех нюансов (и вообще сейчас
меньше всего хочется думать о работе вообще и компьютерах в
частности), но 

> >На статических зависимостях, которые не умеют "оглядываться"
> > -- не вижу, как это делается.  Будь они жесткими или
> Да.

(так чего споришь? :)

> >PS: запихивать все опять в один мешок -- фу.  Лучше захакай эту
> >^&*(^(&^. :(
> Чем тебе не нравится kernel-complete ? Да, это хак.

Это хак, который кривее той цели, которую ты добиваешь.  По
крайней мере мне так сильно кажется.  Т.е. для ряда ситуаций это
выход (за который и я говорил, если ты помнишь), но навязывать
такое гетто всем -- немногим лучше, чем тупо собирать все
статически в ядро.

> Но вполне разумный хак в данной ситуации (мы не можем быстро
> переписать apt-get)

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

Смотри:

- "просто так" обновлять ядро нельзя, потому что может не
  загрузиться как минимум -- на то есть Hold.
  
- при обновлении и вообще для подстраховки рекомендуется иметь
  как минимум предыдущее работавшее ядро, следовательно, надо
  иметь возможность держать в системе несколько ядер, где под
  этим словом подразумевается комплект кода -- необязательно один
  пакет (это имеет место уже довольно давно).
  
  Это справляет Allow-Duplicated.  При этом ломая возможность
  положиться на зависимости субпакетов при обновлении головного
  kernel-image.

- около обновления выполняются пляски по обновлению конфигурации 
  из %post (по минимуму depmod в субпакетах плюс более
  нетривиальные модификации симлинков и конфигурации загрузчика в
  головных пакетах) -- заметь, при росте количества наборов у нас
  есть +/- два выхода:
  
  * макросы/вспомогательные скрипты, которые дергаются заведомо
    однообразно (на сейчас это уже не так для kernel-image-std-up
    по сравнению с kernel24-up -- бардак с симлинками vmlinuz* и
    initrd*, думаю, все наблюдали минимум однажды);

    /это плохо.  Потому, что любые изменения должны быть отражены
    в нескольких местах, а любые ошибки получают лишнюю
    возможность расползтись/

  * инструмент, в который выносится та часть функциональности,
    которая, с одной стороны, достаточно общая для того, чтобы
    вынести ее из пакетов, и с другой стороны, достаточно
    "интеллектуальная" (выбор активного ядра), чтобы не возлагать
    ее на автомат.

    /если человек не хочет пользоваться этой штукой -- получит
    просто все на месте и initrd, но вот бутлоудером займется
    сам/

С учетом того, что вовсе не факт, что я собираюсь грузить
свежеустановленное ядро, а также, возможно, не против
_автоматической_ установки ядра, поступившего как sec update --
но БЕЗ настройки загрузчика на подъем именно его -- а также того,
что такой важный процесс, как собственно конфигурирование этого
самого загрузчика, не может иметь интерактивности в рамках %post
-- мне еще раз кажется, что это отдельная софтина, которая
может/обязана иметь особые отношения с:

* kudzu (<-субпакеты),
* apt (->обновления; установка?),
* rpm (->установка?)

-- нечто вроде select-gcc, который IMCO менее заслуживает
вынесения за рамки alternatives, чем эта задача -- вынесения за
рамки просто зависимостей и PM.

Давай хоть сейчас нарисуем в первом приближении.

Надо:

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

С ходу непонятно, как что-то вроде `uname -r` преобразовать в
SVR.

PS: насчет sec updates -- понимаю, что высказано крайне сумбурно,
но текущая ситуация, кажется, может быть улучшена.

-- 
 ---- WBR, Michael Shigorin <mike at altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/devel-kernel/attachments/20030813/5b80de46/attachment-0002.bin