Re: [devel] obsoleted package

[Led <ledest@gmail.com>]

Sunday, 30 March 2008 19:21:48 Konstantin A. Lepikhov написав:
> Hi Led!
>
> Sunday 30, at 07:02:22 PM you wrote:
> > > Что мешает тебе сделать отдельное ядро + виртуальный пакет?
> >
> > Перманентно печальная судьбы наших kernel-complete отпугивает:) Хотя это
> > тоже вариант решения. Но в случае с ltsp это опять же вносит
> > дополнительные неоднозначности: в принципе, с ltsp можно использовать не
> > только ядро led-tc, но другие ядра, а делать инструкцию "если вы
> > используете led-tc, то делайте просто
> > apt-get install kernel-complete-led-tc
> > , а если другое ядро, то ... и т.д."
>
> Кстати, а если я захочу OVZ контейнер для ltsp (т.е. -ovz-smp + модули)?
> Это будет непоодерживаемой конфигурацией?

led-tc - это клиентское ядро, оно работает только на тонких бездисковых 
клиентах. Открою секрет: там даже smp не включен:) На сервере можно 
использовать хоть std-smp, хоть std-ovz (у нас как раз серверная часть ltsp в 
ovz-контейнере и крутится)

>
> > > Как минимум,
> > > это даст экономию своего времени, поскольку избавит от рутины
> > > пересборки "сторонних" модулей. Более того, наличие отдельного
> > > kernel-source - это 80% работы других мантейнеров для сборки этого
> > > модуля для своих ядер.
> >
> > С этим согласен (про 80%).
> >
> > > Подход "каждой кухарке - свое ядро" вреден тем, что как раз отбрасывает
> > > все эти требования - теперь каждый собирает модули и ядра сам по себе,
> > > не думая о других, что порождает все больше и больше бесплезных ядер,
> > > различающихся только одним патчем/модулем в 2k.
> >
> > А про причины возникновения ситуации "каждой кухарке - свое ядро" ты же
> > знаешь?:)
>
> Нет, не знаю.

Перманентное игнорирование багзиллы, незамечание и "неприветствование"  
готовых патчей и решений. Обид никаких, зато утвердившееся мнение, 
что "спасение утопающих - дело рук самих утопающих".
Основная же "фишка" led-tc - т.н. vm_deadlock-патчи. Они существовали 
изначально только для >=2.6.21. После того как другие мои бэкпорты на 2.6.18 
были проигнорированы, я даже не пытался портировать vm_deadlock на основное в 
тот момент 2.6.18. На тот момент работоспособность ltsp5 в Сизифе 
интересовала только меня и ещё пару человек, поэтому я понял, что всё нужно 
делать самому: и ядро, и mkinitrd и т.п. Я потерял много времени пытаясь кого 
в чём-то убеждить, но зато теперь точно знаю, что потерял это время зря и в 
дальнейшем этого делать не буду:)
Думаю, что остальные "кухарки" руководствовались схожими мотивами:)

> Я знаю, что текущее состояние с ядрами у нас настолько 
> хреновое, что даже стыдно пользоваться каким-нибудь несобственным/неvsu
> kernel-трам-пам-пам из сизифа ;)

Мне - не стыдно... просто - стрёмно:)

>
> > > Привычка обновлять ядро без причины - вредная привычка. И с ней
> > > неустанно боролись :)
> >
> > Не передёргивай: есть ещё варианты (нередкие) "привычка обновлять ядро С
> > ПРИЧИНОЙ":)
>
> А привычка бэкпортить что нравится не развита? Перенос вкусных фишек в
> -stable это как раз и есть работа мантейнера, а не мартышки, делающей git
> fetch из git.kernel.org и переносящей собранный тарболл в сизиф (пример с
> мартышкой отвлеченный ;) Более того, это не работа пользователя обновлять
> ядра, пользователь хочет функционал, пинает манейнера, который чешет репу
> и собирает ядро с заданным функционалом.

Пользователь "пинает" своего админа, а не мейнтейнера.

>
> > > > оверхеде по объёму (да, я знаю про всевозможные костыли-скрипты от
> > > > разных авторов, которые "обновляют всё и красиво вместе с ядром", но
> > > > от этого они перестают быть костылями). А по факту - ядра обновляются
> > > > чаще, чем 90% "внешних модулей", которые потом "догоняют" ядро в
> > > > репозитарии в течении нескольких дней. Но "догоняют" только
> > > > формально, потому как множество kernel-source-module остаются
> > > > безнадёжно устаревшими по версиям
> > > >
> > > > :(
> > >
> > > Если собирать себе каждый день снапшоты из git, то да, модули будут
> > > отставать по версиям.
> >
> > Опять не передёргивай: я говорил о ВЕРСИЯХ, с вдумчивым прочтением
> > ChangeLog'а (хотя в случае с drm имеет смысл смотреть и на "снапщоты
> > git")
>
> см. выше - иногда лучше прочитать, плюнуть и сделать свой -feat на текущее
> ядро. Поскольку маленький кусок всегда лучше читается, чем 100Мб кода.

Я и сделал -feat'ы вместо устаревших "внешних модулей" - в чём тогда 
заключаются твои притензии?

> > > В других случаях описанная ситутация кажется мне
> > > сильно надуманной. kernel-source у нас устаревают не потому, что ядро
> > > их обгоняет, а потому что их собирать и чинить некому.
> >
> > Воот! То, что я не осмелился сказать - ты озвучил. Вот я и не хочу
> > зависеть от этих "некому":) В kernel-image-led-tc все "как бы внешние"
> > модули совсем не тех версий, что в сизифе (кроме kernel-source-usbip,
> > который я же в сизиф и собираю):)
>
> Я осмелюсь на большее - чем дальше, тем хуже. Думаю, новый дистрибутив
> альтилинукс будет сделан на ядре с проприетарной лицензией, собранном
> где-то за пределами офиса (если, конечно, ситуация не улучшится).

Без комментариев:)

-- 
Led