From: Michael Shigorin <mike@osdn.org.ua> To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> Subject: Re: [d-kernel] Опять грабли с новой схемой сборки Date: Wed, 13 Aug 2003 16:23:46 +0300 Message-ID: <20030813132346.GQ17550@osdn.org.ua> (raw) In-Reply-To: <3F3A2E1C.1020807@altlinux.com> [-- 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 --]
next prev parent reply other threads:[~2003-08-13 13:23 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-08-13 8:15 Anton Farygin 2003-08-13 8:32 ` [d-kernel] ïÐÑÔØ ÇÒÁÂÌÉ Ó ÎÏ×ÏÊ ÓÈÅÍÏÊ ÓÂÏÒËÉ Ed V. Bartosh 2003-08-13 10:43 ` [d-kernel] Опять грабли с новой схемой сборки Anton Farygin 2003-08-13 12:16 ` Michael Shigorin 2003-08-13 12:25 ` Anton Farygin 2003-08-13 12:34 ` Sergey Bolshakov 2003-08-13 13:14 ` [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 2003-08-13 13:25 ` [d-kernel] i"?N~O^? C, O`A'A^I`E' " Michael Shigorin 2003-08-13 13:51 ` Anton Farygin 2003-08-13 14:25 ` [d-kernel] Опять грабли с инсталером Michael Shigorin 2003-08-13 15:40 ` Anton Farygin 2003-08-14 8:06 ` Michael Shigorin 2003-08-14 11:03 ` Anton Farygin 2003-08-14 13:27 ` Michael Shigorin 2003-08-14 13:43 ` Anton Farygin 2003-08-14 13:49 ` Michael Shigorin 2003-08-13 13:23 ` Michael Shigorin [this message] 2003-08-13 13:53 ` [d-kernel] Re: Опять грабли с новой схемой сборки Sergey Vlasov 2003-08-13 15:01 ` [d-kernel] kernel-module-list.sh (was: Опять грабли с инсталером) Michael Shigorin 2003-08-13 16:16 ` [d-kernel] " Sergey Vlasov 2003-08-14 8:09 ` Michael Shigorin 2003-08-14 14:19 ` Sergey Vlasov 2003-08-15 19:53 ` [d-kernel] Опять грабли с новой схемой сборки Dmitry V. Levin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20030813132346.GQ17550@osdn.org.ua \ --to=mike@osdn.org.ua \ --cc=devel-kernel@altlinux.ru \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux kernel packages development This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel-kernel/0 devel-kernel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel-kernel devel-kernel/ http://lore.altlinux.org/devel-kernel \ devel-kernel@altlinux.org devel-kernel@altlinux.ru devel-kernel@altlinux.com public-inbox-index devel-kernel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git