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

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

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 968 bytes --]

Всем привет !

Один вопрос:

Как пользователь должен обновлять пакеты с ядрами?

apt-get install kernel-image-std-up не обновляет все модули, которые 
были у него установлены

а _стандартный_ пользователь может не знать какие у него стояли модули 
раньше... мало того - могут появится новые пакеты с модулями.

Что делать ?

Я опять предлагаю вернутся к старой схеме: один пакет - все модули.

Либо доработать существующую в CVS схему сборки ядра (кто? мне сейчас 
совсем некогда) для того, что бы при сборке kernel-modules генерить 
пакет kernel-complete с зависимостями уже на version-release.

Соостветственно после этого пакеты с ядрами, которые не вытаскивает ни 
один kernel-complete: убрать из Sisyphus.

Также предлагаю жестко прописать расположение каталогов с модулями 
внутри kernel-image.

В очередной сборке ядра оказался поломан pcmcia, ибо исчез катало 
/lib/modules/`uname -r`/pcmcia, из которого грузились ранее модули 
pcmcia_core и др.

Rgds,
Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [d-kernel] ïÐÑÔØ ÇÒÁÂÌÉ Ó ÎÏ×ÏÊ ÓÈÅÍÏÊ ÓÂÏÒËÉ

[Ed V. Bartosh]

>>>>> "AF" == Anton Farygin writes:

 AF>  Как пользователь должен обновлять пакеты с ядрами?
  
 AF>  apt-get install kernel-image-std-up не обновляет все модули,
 AF>  которые были у него установлены
apt-get upgrade разве не обновит те модули, которые установлены,
после установки соответствующего ядра ?

 AF>  а _стандартный_ пользователь может не знать какие у него стояли
 AF>  модули раньше... мало того - могут появится новые пакеты с
 AF>  модулями.
Могут появиться новые пакеты не только с модулями :) Их тоже того,
ставить ?
  
-- 
Best regards,
Ed V. Bartosh

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

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

Ed V. Bartosh пишет:
>>>>>>"AF" == Anton Farygin writes:
> 
> 
>  AF>  Как пользователь должен обновлять пакеты с ядрами?
>   
>  AF>  apt-get install kernel-image-std-up не обновляет все модули,
>  AF>  которые были у него установлены
> apt-get upgrade разве не обновит те модули, которые установлены,
> после установки соответствующего ядра ?

Нет.

Вообще стандартно ядра устанавливаются через install. Это позволяет 
иметь старое и новое ядро одновременно.

> 
>  AF>  а _стандартный_ пользователь может не знать какие у него стояли
>  AF>  модули раньше... мало того - могут появится новые пакеты с
>  AF>  модулями.
> Могут появиться новые пакеты не только с модулями :) Их тоже того,
> ставить ?

Нет. речь идет только о пакетах с модулями.

Еще один пример:

nvidia_glx хочет ядерный пакет kernel-modules-nvidia

В системе установлено одно ядро и пользователь ставит еще одно ядро, 
более новой версии.

Rgds,
Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

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

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 805 bytes --]

On Wed, Aug 13, 2003 at 12:15:56PM +0400, Anton Farygin wrote:
> Как пользователь должен обновлять пакеты с ядрами?

Возможно, для этого стоит сделать отдельную тулзень, которая
будет иметь достаточно специфический интеллект.

Раздумий над вопросом было довольно много, и на пока мне кажется,
что в рамках rpm/apt как _generic_ PM это не укладывается -- там
и так хватает хаков вроде Hold и Allow-Duplicated.

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

PS: запихивать все опять в один мешок -- фу.  Лучше захакай эту
^&*(^(&^. :(

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 950 bytes --]

Michael Shigorin пишет:
> On Wed, Aug 13, 2003 at 12:15:56PM +0400, Anton Farygin wrote:
> 
>>Как пользователь должен обновлять пакеты с ядрами?
> 
> 
> Возможно, для этого стоит сделать отдельную тулзень, которая
> будет иметь достаточно специфический интеллект.

Нет. Это не выход.

> 
> Раздумий над вопросом было довольно много, и на пока мне кажется,
> что в рамках rpm/apt как _generic_ PM это не укладывается -- там
> и так хватает хаков вроде Hold и Allow-Duplicated.

Да.

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

Да.

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

Чем тебе не нравится kernel-complete ? Да, это хак. Но вполне разумный 
хак в данной ситуации (мы не можем быстро переписать apt-get)

Rgds,
Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

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

[Sergey Bolshakov]

>>>>> "Anton" == Anton Farygin <rider@altlinux.com> writes:

 > Michael Shigorin пишет:
 >> On Wed, Aug 13, 2003 at 12:15:56PM +0400, Anton Farygin wrote:
 >> 
 >>> Как пользователь должен обновлять пакеты с ядрами?
 >> Возможно, для этого стоит сделать отдельную тулзень, которая
 >> будет иметь достаточно специфический интеллект.

 > Нет. Это не выход.

 >> Раздумий над вопросом было довольно много, и на пока мне кажется,
 >> что в рамках rpm/apt как _generic_ PM это не укладывается -- там
 >> и так хватает хаков вроде Hold и Allow-Duplicated.

 > Да.

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

 > Да.

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

 > Чем тебе не нравится kernel-complete ? Да, это хак. Но вполне разумный
 > хак в данной ситуации (мы не можем быстро переписать apt-get)

Тем, что это лекарство не лечит.
Смысл распиливания ядра был в т.ч. в том, чтобы иметь
возможность не ставить того, что не нужно, следовательно,
kernel-complete в значительной части инсталляций проставлен
не будет.

-- 

Re: [d-kernel] i"?N~O^? C,O`A'A^I`E' O' I^I"?I"E^ O'E`A*I'I"E^ O'A^I"O`E"E'

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 1555 bytes --]

Sergey Bolshakov пишет:
>>>>>>"Anton" == Anton Farygin <rider@altlinux.com> writes:
> 
> 
>  > Michael Shigorin пишет:
>  >> On Wed, Aug 13, 2003 at 12:15:56PM +0400, Anton Farygin wrote:
>  >> 
>  >>> Как пользователь должен обновлять пакеты с ядрами?
>  >> Возможно, для этого стоит сделать отдельную тулзень, которая
>  >> будет иметь достаточно специфический интеллект.
> 
>  > Нет. Это не выход.
> 
>  >> Раздумий над вопросом было довольно много, и на пока мне кажется,
>  >> что в рамках rpm/apt как _generic_ PM это не укладывается -- там
>  >> и так хватает хаков вроде Hold и Allow-Duplicated.
> 
>  > Да.
> 
>  >> На статических зависимостях, которые не умеют "оглядываться"
>  >> (например, новое ядро "видит" уже установленные к старому модули
>  >> и начинает жаждать и себе) -- не вижу, как это делается.  Будь
>  >> они жесткими или "suggested".
> 
>  > Да.
> 
>  >> PS: запихивать все опять в один мешок -- фу.  Лучше захакай эту
>  >> ^&*(^(&^. :(
> 
>  > Чем тебе не нравится kernel-complete ? Да, это хак. Но вполне разумный
>  > хак в данной ситуации (мы не можем быстро переписать apt-get)
> 
> Тем, что это лекарство не лечит.
> Смысл распиливания ядра был в т.ч. в том, чтобы иметь
> возможность не ставить того, что не нужно, следовательно,
> kernel-complete в значительной части инсталляций проставлен
> не будет.

В данный момент kernel-complete (и все, что он тащит) будет поставлен 
_всегда_.

Мне пришлось сделать такой хак в инсталяторе, ибо переписывать текущий 
инсталятор в данный момент времени нет смысла.

Rgds,
Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

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

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 4123 bytes --]

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@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] i"?N~O^? C, O`A'A^I`E' O' I^I"?I"E^ O'E`A*I'I"E^ O'A^I"O`E"E'

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 455 bytes --]

On Wed, Aug 13, 2003 at 05:14:41PM +0400, Anton Farygin wrote:
> Мне пришлось сделать такой хак в инсталяторе, ибо переписывать
> текущий инсталятор в данный момент времени нет смысла.

Антон, это все понятно, но это мухи, а не котлеты.  Это проблема
_инсталятора_, и если ломать и автогенить -- то его, а не все
вокруг под тот же радиус загибать.

Правда?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] i"?N~O^? C, O`A'A^I`E' O' I^I"?I"E^ O'E`A*I'I"E^ O'A^I"O`E"E'

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]

Michael Shigorin пишет:
> On Wed, Aug 13, 2003 at 05:14:41PM +0400, Anton Farygin wrote:
> 
>>Мне пришлось сделать такой хак в инсталяторе, ибо переписывать
>>текущий инсталятор в данный момент времени нет смысла.
> 
> 
> Антон, это все понятно, но это мухи, а не котлеты.  Это проблема
> _инсталятора_, и если ломать и автогенить -- то его, а не все
> вокруг под тот же радиус загибать.
> 
> Правда?

Неправда.

У нас сейчас нет ресурсов для загибания всего и вся под kernel

Соотственно проще загнуть kernel подо все.

Rgds,
Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

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

[Sergey Vlasov]

On Wed, 13 Aug 2003 16:23:46 +0300
Michael Shigorin <mike@osdn.org.ua> wrote:

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

А это он каким местом ломает? Зависимости там как раз отслеживаются
нормально.

Там сломано другое: нет возможности нормально сделать обновление
пакета с модулем без обновления основного ядра (apt-get install
kernel-modules-something\#.... в этом случае должен бы удалить
предыдущую версию пакета с модулями - но только ту, которая
действительно собрана для того же ядра).

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

И, кстати, здесь есть ещё один источник граблей - если всё-таки
выносить какие-либо SCSI-модули в отдельные пакеты, mkinitrd нужно
вызывать после установки не только ядра, а и этих пакетов.

> Давай хоть сейчас нарисуем в первом приближении.
> 
> Надо:
> 
> - определить текущее ядро
> - получить список установленных пакетов с модулями, которые его
>   требуют
> - проверить его на доступность в версиях, которые требуют
>   устанавливаемое ядро
> 
> С ходу непонятно, как что-то вроде `uname -r` преобразовать в
> SVR.

rpmquery -qf /boot/vmlinuz-"`uname -r`"

Re: [d-kernel] Опять грабли с инсталером

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]

On Wed, Aug 13, 2003 at 05:51:35PM +0400, Anton Farygin wrote:
> >>Мне пришлось сделать такой хак в инсталяторе, ибо переписывать
> >>текущий инсталятор в данный момент времени нет смысла.
> >Антон, это все понятно, но это мухи, а не котлеты.  Это проблема
> >_инсталятора_, и если ломать и автогенить -- то его, а не все
> >вокруг под тот же радиус загибать.  Правда?
> Неправда.  У нас сейчас нет ресурсов для загибания всего и вся
> под kernel Соотственно проще загнуть kernel подо все.

<lyrics>
Потом не будет ресурсов разогнуть, а потом в результате
сгибания-разгибания корова наконец сдохнет.

Видишь ли, это мы проходили не раз, и лично я последний раз --
вот за эти полгода.  Тут тоже имели глупость избрать в какой-то
момент времени такую "стратегию" и, понимаешъ, расхлебываем-с.
</lyrics>

По сути: чем отличается выгребание тобой зависимостей того же
kernel-complete для инсталятора от такой же процедуры для
каких-нибудь sh-utils?  Ну не уразумею никак :(

И объясни мне, что так драматически изменилось с тех пор, когда
_уже_ был этот же инсталятор и как минимум kernel24-up и
alsa24-up?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[d-kernel] kernel-module-list.sh (was: Опять грабли с инсталером)

[Michael Shigorin]

[-- Attachment #1.1: Type: text/plain, Size: 2537 bytes --]

On Wed, Aug 13, 2003 at 05:53:22PM +0400, Sergey Vlasov wrote:
> >   Это справляет Allow-Duplicated.  При этом ломая возможность
> >   положиться на зависимости субпакетов при обновлении головного
> >   kernel-image.
> А это он каким местом ломает? Зависимости там как раз
> отслеживаются нормально.

Это не обвинение, это просто не его компетенция.

Пусть есть:

kernel-image-F-V-R
kernel-modules-N-F-V'-R'

Надо поставить рядом:

kernel-image-F-V1-R1 (или даже -F1, где F1 != F)

и при этом обеспечить установку kernel-modules-N-F-V''-R'',
которое собрано для этого второго ядра.  (кстати, не уверен, что
случай со сменой flavour стоит пытаться обработать здесь же)

Мы можем только требовать +/- точную версию/сборку ядра в
kernel-modules, но не наоборот.  Следовательно, ситуация почти
подпадает под dist-upgrade, но при этом комбинация Hold и
Allow-Duplicated заблокирует этот путь.  Да и желание обновить
именно "ядерные силы" может быть вполне точечным.

В принципе, подобные ситуации (необходимость установки
параллельно нескольких версий плюс разлробленность пакета) вроде
как встречались еще в случае или двух -- но ядро отличается как
минимум той ответственностью процедуры, которая пусть лучше
требует внимания администратора, при этом из apt-rpm мы точно
вылетаем; на apt+dpkg интерактивность позволена, у нас ее нет.

В сумме получается действительно что-то параллельное apt,
возможно, разве что использующее его "втупую" с указанием точных
версий -- как rpm с уже настроенным транспортом -- если
нижеуказанные грабли это не сломают.

Может, это такой себе apt-kernel, который может пользовать
транспортные возможности и разрешение зависимостей по данным
кэша, но имеет более специфические логику и интерфейс?

> Там сломано другое: нет возможности нормально сделать
> обновление пакета с модулем без обновления основного ядра
> (apt-get install kernel-modules-something\#.... в этом случае
> должен бы удалить предыдущую версию пакета с модулями - но
> только ту, которая действительно собрана для того же ядра).

И это тоже.

> > - определить текущее ядро
> > - получить список установленных пакетов с модулями, которые его
> >   требуют
> > - проверить его на доступность в версиях, которые требуют
> >   устанавливаемое ядро
> > С ходу непонятно, как что-то вроде `uname -r` преобразовать в
> > SVR.
> rpmquery -qf /boot/vmlinuz-"`uname -r`"

Точно, спасибо :)

Тогда получается скриптик, который делает первых два шага.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #1.2: kernel-module-list.sh --]
[-- Type: text/plain, Size: 209 bytes --]

#!/bin/sh
[ "$EUID" != 0 ] && CMD="sudo" || CMD=""
rpm -q --queryformat '%{NAME}\n' $(
	rpm -q --whatrequires $(
		rpm -q --queryformat '%{NAME}\n' $(
			$CMD rpmquery -qf /boot/vmlinuz-"$(uname -r)"
		)
	)
)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] Опять грабли с инсталером

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 2757 bytes --]

Michael Shigorin пишет:
> On Wed, Aug 13, 2003 at 05:51:35PM +0400, Anton Farygin wrote:
> 
>>>>Мне пришлось сделать такой хак в инсталяторе, ибо переписывать
>>>>текущий инсталятор в данный момент времени нет смысла.
>>>
>>>Антон, это все понятно, но это мухи, а не котлеты.  Это проблема
>>>_инсталятора_, и если ломать и автогенить -- то его, а не все
>>>вокруг под тот же радиус загибать.  Правда?
>>
>>Неправда.  У нас сейчас нет ресурсов для загибания всего и вся
>>под kernel Соотственно проще загнуть kernel подо все.
> 
> 
> <lyrics>
> Потом не будет ресурсов разогнуть, а потом в результате
> сгибания-разгибания корова наконец сдохнет.
> 
> Видишь ли, это мы проходили не раз, и лично я последний раз --
> вот за эти полгода.  Тут тоже имели глупость избрать в какой-то
> момент времени такую "стратегию" и, понимаешъ, расхлебываем-с.
> </lyrics>
> 
> По сути: чем отличается выгребание тобой зависимостей того же
> kernel-complete для инсталятора от такой же процедуры для
> каких-нибудь sh-utils?  Ну не уразумею никак :(
> 
> И объясни мне, что так драматически изменилось с тех пор, когда
> _уже_ был этот же инсталятор и как минимум kernel24-up и
> alsa24-up?

Уже наверное в восьмой раз повторяю:

в инсталяторе хардкорно прописываются модули для установки.. выглядет 
это так:

         push @{$o->{default_packages}}, "kernel-modules-alsa-std-up", 
"alsa2-utils", "aumix" if modules::get_al
ias("sound-slot-0") =~ /^snd-/; 

         push @{$o->{default_packages}}, "hsflinmodem", 
"kernel-modules-hsflinmodem-std-up"
                 if grep { $_->{driver} eq 'hsfserial' } 
detect_devices::probeall();
         push @{$o->{default_packages}}, "kernel-modules-slmdm-data", 
"kernel-modules-slmdm-std-up"
                 if grep { $_->{driver} eq 'slamrmo' } 
detect_devices::probeall();

Вот теперь представь себе, что количество таких пакетов растет каждый 
день...

Сейчас я сделал такой хак:

         push @{$o->{default_packages}}, "kernel-image-std-up", 
"kernel-modules-drm-std-up", "kernel-modules-slm
dm-data", 

          "kernel-modules-slmdm-std-up", 
"kernel-modules-bcm5700-std-up", "kernel-modules-pctel-std-up", "kernel
-modules-sensors-std-up", 

           "kernel-modules-nvidia-nforce-std-up" if !$::oem && 
c::kernel_version() =~ /^\Q2.4/;

А kernel-complete не получается в инсталяторе использовать, т.к. у него 
конкретно сломана идеология работы с виртуальными пакетами и с 
зависимостями. Это лечится только переписыванием. Впрочем - если есть 
желание: можешь попробовать поправить (заодно исправив apt-get, kudzu и 
все остальное).

Rgds,
Rider

P.S.

Образ compact и installer с последними версиями XFree-4.3.0 и 
kernel-image-std-up закачивается на ftp.altlinux.ru/pub/people/rider/ISO/

Changelog приложен

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

[d-kernel] Re: kernel-module-list.sh (was: Опять грабли с инсталером)

[Sergey Vlasov]

On Wed, 13 Aug 2003 18:01:51 +0300
Michael Shigorin <mike@osdn.org.ua> wrote:

> [kernel-module-list.sh  text/plain (320 bytes)]
> #!/bin/sh
> [ "$EUID" != 0 ] && CMD="sudo" || CMD=""
> rpm -q --queryformat '%{NAME}\n' $(
> 	rpm -q --whatrequires $(
> 		rpm -q --queryformat '%{NAME}\n' $(
> 			$CMD rpmquery -qf /boot/vmlinuz-"$(uname -r)"
> 		)
> 	)
> )

sudo там не нужен - rpmquery -qf и без него работает (а вот если дать
несуществующий файл, действительно говорит Permission denied).

Правда, этот скрипт выдаёт кучу мусора (одни и те же имена по
нескольку раз, плюс устаревшие имена от старых версий).

Re: [d-kernel] Опять грабли с инсталером

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 926 bytes --]

On Wed, Aug 13, 2003 at 07:40:29PM +0400, Anton Farygin wrote:
> >И объясни мне, что так драматически изменилось с тех пор, когда
> >_уже_ был этот же инсталятор и как минимум kernel24-up и
> >alsa24-up?
> Уже наверное в восьмой раз повторяю:

Ну.

> в инсталяторе хардкорно прописываются модули для установки..
> выглядет это так:

Да.

> Вот теперь представь себе, что количество таких пакетов растет
> каждый день...

Ты дистрибутив каждый день выпускаешь?

> А kernel-complete не получается в инсталяторе использовать,

Я помню, ты ж рассказывал.  _Но_ не менее ли злым хаком будет
ПРОСТО ПРИБИТЬ ГВОЗДЯМИ установку ВСЕХ ядерных пакетов как
альтернативу установке kernel-complete, с которой инсталер не
может справиться?  Для данного конкретного выпуска (и его бет)?

[этот кусок уйдет лично]

> Changelog приложен

Не-а :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] Re: kernel-module-list.sh (was: Опять грабли с инсталером)

[Michael Shigorin]

On Wed, Aug 13, 2003 at 08:16:37PM +0400, Sergey Vlasov wrote:
> > #!/bin/sh
> > [ "$EUID" != 0 ] && CMD="sudo" || CMD=""
> > rpm -q --queryformat '%{NAME}\n' $(
> > 	rpm -q --whatrequires $(
> > 		rpm -q --queryformat '%{NAME}\n' $(
> > 			$CMD rpmquery -qf /boot/vmlinuz-"$(uname -r)"
> > 		)
> > 	)
> > )
> sudo там не нужен - rpmquery -qf и без него работает (а вот если дать
> несуществующий файл, действительно говорит Permission denied).

Да.  Кстати, зря это прозвучало -- сейчас Дима исправит rpm на
манер slocate и это сломается. %)

> Правда, этот скрипт выдаёт кучу мусора (одни и те же имена по
> нескольку раз, плюс устаревшие имена от старых версий).

Я его перед отъездом на дачу еле набросал и даже не успел
проверить на пачке_ядер :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [d-kernel] Опять грабли с инсталером

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 1195 bytes --]

Michael Shigorin пишет:
> On Wed, Aug 13, 2003 at 07:40:29PM +0400, Anton Farygin wrote:
> 
>>>И объясни мне, что так драматически изменилось с тех пор, когда
>>>_уже_ был этот же инсталятор и как минимум kernel24-up и
>>>alsa24-up?
>>
>>Уже наверное в восьмой раз повторяю:
> 
> 
> Ну.
> 
> 
>>в инсталяторе хардкорно прописываются модули для установки..
>>выглядет это так:
> 
> 
> Да.
> 
> 
>>Вот теперь представь себе, что количество таких пакетов растет
>>каждый день...
> 
> 
> Ты дистрибутив каждый день выпускаешь?

Да.

> 
> 
>>А kernel-complete не получается в инсталяторе использовать,
> 
> 
> Я помню, ты ж рассказывал.  _Но_ не менее ли злым хаком будет
> ПРОСТО ПРИБИТЬ ГВОЗДЯМИ установку ВСЕХ ядерных пакетов как
> альтернативу установке kernel-complete, с которой инсталер не
> может справиться?  Для данного конкретного выпуска (и его бет)?

А где взять список _всех_ ядерных пакетов ежедневно и желательно 
автоматом что бы это в инсталятор прописывалось ?

Я могу конечно сделать совсем конкретный хак, типа apt-cache search 
kernel-|grep std-up и патчить этим инсталлер при каждой сборке.. но это 
уже такой конкретный хак ;-)

И как же быть с apt-get и kudzu ?

Rgds,
Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [d-kernel] Опять грабли с инсталером

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]

On Thu, Aug 14, 2003 at 03:03:30PM +0400, Anton Farygin wrote:
> >>Вот теперь представь себе, что количество таких пакетов
> >>растет каждый день...
> >Ты дистрибутив каждый день выпускаешь?
> Да.

Нет.  Это бета, а не дистрибутив.  И время выпуска каждой беты у
тебя есть конкретный набор таких пакетов.

Мне тоже жаль, что тебе приходится это делать вручную.

> >ПРОСТО ПРИБИТЬ ГВОЗДЯМИ установку ВСЕХ ядерных пакетов как
> А где взять список _всех_ ядерных пакетов ежедневно и
> желательно автоматом что бы это в инсталятор прописывалось ?

Ммм...

> Я могу конечно сделать совсем конкретный хак, типа apt-cache
> search kernel-|grep std-up и патчить этим инсталлер при каждой
> сборке.. но это уже такой конкретный хак ;-)

Дык.  Хотя, сдается мне, нечто вроде whatrequires
kernel-image-std-up | grep ^kernel-module будет и то чище?

Или тебя восхищает собственно патченье по мотивам репозитория? :]

> И как же быть с apt-get и kudzu ?

В плане приучения последнего к первому, что ли?  Если
действительно прибить гвоздями (безусловно устанавливать -- не
вижу, чем это хуже запихивания всего в один (мета)пакет) -- для
compact тебе это и не понадобится.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] Опять грабли с инсталером

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 1925 bytes --]

Michael Shigorin пишет:
> On Thu, Aug 14, 2003 at 03:03:30PM +0400, Anton Farygin wrote:
> 
>>>>Вот теперь представь себе, что количество таких пакетов
>>>>растет каждый день...
>>>
>>>Ты дистрибутив каждый день выпускаешь?
>>
>>Да.
> 
> 
> Нет.  Это бета, а не дистрибутив.  И время выпуска каждой беты у
> тебя есть конкретный набор таких пакетов.
> 
> Мне тоже жаль, что тебе приходится это делать вручную.

Жалость мне не помошник ;-)

> 
> 
>>>ПРОСТО ПРИБИТЬ ГВОЗДЯМИ установку ВСЕХ ядерных пакетов как
>>
>>А где взять список _всех_ ядерных пакетов ежедневно и
>>желательно автоматом что бы это в инсталятор прописывалось ?
> 
> 
> Ммм...
> 
> 
>>Я могу конечно сделать совсем конкретный хак, типа apt-cache
>>search kernel-|grep std-up и патчить этим инсталлер при каждой
>>сборке.. но это уже такой конкретный хак ;-)
> 
> 
> Дык.  Хотя, сдается мне, нечто вроде whatrequires
> kernel-image-std-up | grep ^kernel-module будет и то чище?

[rider@riderbook rider]$ rpm -q --whatrequires kernel-image-std-up
kernel-modules-alsa-std-up-0.9.4-alt4
kernel-modules-alsa-std-up-0.9.6-alt6
kernel-modules-sensors-std-up-2.8.0-alt4

Это все. В общем это не решение.

> 
> Или тебя восхищает собственно патченье по мотивам репозитория? :]

Мне нужно решение, максимально снижающее трудозатраты на разработку. И 
максимально облегчающее жизнь инкамингерам и мантейнерам ядра.

> 
> 
>>И как же быть с apt-get и kudzu ?
> 
> 
> В плане приучения последнего к первому, что ли?  Если
> действительно прибить гвоздями (безусловно устанавливать -- не
> вижу, чем это хуже запихивания всего в один (мета)пакет) -- для
> compact тебе это и не понадобится.

Нет. В плане приученья kudzu вытаскивать нужные пакеты с модулями для 
найденного оборудования и apt-get - в плане корректного upgrade ядра 
вместе с установленными модулями (тут nidd вчера нашептал Lua, но тогда 
нужно apt-get перетаскивать из daedalus в Sisyphus)

Rgds,
Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [d-kernel] Опять грабли с инсталером

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]

On Thu, Aug 14, 2003 at 05:43:24PM +0400, Anton Farygin wrote:
> [rider@riderbook rider]$ rpm -q --whatrequires kernel-image-std-up
> kernel-modules-alsa-std-up-0.9.4-alt4
> kernel-modules-alsa-std-up-0.9.6-alt6

Выбираем старшего.

> kernel-modules-sensors-std-up-2.8.0-alt4
> Это все. В общем это не решение.

А может, все-таки пофиксить субпакеты, которые не хотят ядро,
хотя должны бы?

> >>И как же быть с apt-get и kudzu ?
> >В плане приучения последнего к первому, что ли?
> Нет. В плане приученья kudzu вытаскивать нужные пакеты с
> модулями для найденного оборудования

"Вытаскивать" -- откуда?  Сейчас оно вроде urpmi для этого
пользовало? (давно не наблюдал)

> и apt-get - в плане корректного upgrade ядра вместе с
> установленными модулями (тут nidd вчера нашептал Lua, но тогда
> нужно apt-get перетаскивать из daedalus в Sisyphus)

Ладно, пас.

> >Если действительно прибить гвоздями (безусловно устанавливать
> >-- не вижу, чем это хуже запихивания всего в один (мета)пакет)
> >-- для compact тебе это и не понадобится.

?

PS: можно, конечно, в новые ядра писать, что они Obsoletes:
старые kernel-module-* (все для своего flavour) -- но :((

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[d-kernel] Re: kernel-module-list.sh (was: Опять грабли с инсталером)

[Sergey Vlasov]

On Thu, 14 Aug 2003 11:09:07 +0300
Michael Shigorin <mike@osdn.org.ua> wrote:

> On Wed, Aug 13, 2003 at 08:16:37PM +0400, Sergey Vlasov wrote:
> > > #!/bin/sh
> > > [ "$EUID" != 0 ] && CMD="sudo" || CMD=""
> > > rpm -q --queryformat '%{NAME}\n' $(
> > > 	rpm -q --whatrequires $(
> > > 		rpm -q --queryformat '%{NAME}\n' $(
> > > 			$CMD rpmquery -qf /boot/vmlinuz-"$(uname -r)"
> > > 		)
> > > 	)
> > > )
> > sudo там не нужен - rpmquery -qf и без него работает (а вот если дать
> > несуществующий файл, действительно говорит Permission denied).
> 
> Да.  Кстати, зря это прозвучало -- сейчас Дима исправит rpm на
> манер slocate и это сломается. %)

Так сейчас весь /var/lib/rpm world readable.

Хотя для данного применения это несущественно - всё равно пакеты будет
ставить root.

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 659 bytes --]

On Wed, Aug 13, 2003 at 12:15:56PM +0400, Anton Farygin wrote:
> Как пользователь должен обновлять пакеты с ядрами?

Лучше всего, если для этого будет достаточно стандартного
apt-get dist-upgrade

> apt-get install kernel-image-std-up не обновляет все модули, которые 
> были у него установлены
> 
> а _стандартный_ пользователь может не знать какие у него стояли модули 
> раньше... мало того - могут появится новые пакеты с модулями.
> 
> Что делать ?

Для начала, немного подождать новой версии apt-rpm, в которой, скорее
всего, появится соответствующая функциональность:
http://distro2.conectiva.com.br/pipermail/apt-rpm/2003-August/001933.html


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]