[devel] obsoleted package

[devel] obsoleted package

[Led]

Прошу отправить в obsolete пакет
kernel-modules-compc ache-led-tc

-- 
Led

Re: [devel] obsoleted package

[Денис Смирнов]

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

On Sat, Mar 29, 2008 at 08:44:34PM +0200, Led wrote:
L> Прошу отправить в obsolete пакет
L> kernel-modules-compc ache-led-tc

Оно не заработало?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] obsoleted package

[Led]

Sunday, 30 March 2008 02:10:06 Денис Смирнов написав:
> On Sat, Mar 29, 2008 at 08:44:34PM +0200, Led wrote:
> L> Прошу отправить в obsolete пакет
> L> kernel-modules-compc ache-led-tc
>
> Оно не заработало?

По-моему, отлично работает. Просто на данный момент я включил его в 
kernel-image-led-tc, версию 0.3

-- 
Led

Re: [devel] obsoleted package

[Konstantin A. Lepikhov]

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

Hi Led!

Sunday 30, at 02:48:21 AM you wrote:

> Sunday, 30 March 2008 02:10:06 Денис Смирнов написав:
> > On Sat, Mar 29, 2008 at 08:44:34PM +0200, Led wrote:
> > L> Прошу отправить в obsolete пакет
> > L> kernel-modules-compc ache-led-tc
> >
> > Оно не заработало?
> 
> По-моему, отлично работает. Просто на данный момент я включил его в 
> kernel-image-led-tc, версию 0.3
А ты можешь популярно объяснить, зачем kernel-image-led носит все с собой?

-- 
WBR et al.

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

Re: [devel] obsoleted package

[Led]

Sunday, 30 March 2008 11:44:23 Konstantin A. Lepikhov написав:
> Hi Led!
>
> Sunday 30, at 02:48:21 AM you wrote:
> > Sunday, 30 March 2008 02:10:06 Денис Смирнов написав:
> > > On Sat, Mar 29, 2008 at 08:44:34PM +0200, Led wrote:
> > > L> Прошу отправить в obsolete пакет
> > > L> kernel-modules-compc ache-led-tc
> > >
> > > Оно не заработало?
> >
> > По-моему, отлично работает. Просто на данный момент я включил его в
> > kernel-image-led-tc, версию 0.3
>
> А ты можешь популярно объяснить, зачем kernel-image-led носит все с собой?

Навскидку - 3 субъективных момента:
1) мне так удобнее
2) удобнее обновлять в LTSP-чруте
3) не нужно руками перегенерировать initrd после установки ядра и необходимых 
Ethernet-модулей.
Ко всему прочему, я так и не понял логику: почему пакет kernel-image-* таскает 
всё с собой (даже очень редко используемые модули), а те модули, которые 
используются на порядок чаще - в отдельных пакетах:)

-- 
Led

Re: [devel] obsoleted package

[Igor Zubkov]

30.03.08, Led<ledest@gmail.com> написал(а):
>  > L> Прошу отправить в obsolete пакет
>  > L> kernel-modules-compc ache-led-tc
>  >
>  > Оно не заработало?
>
> По-моему, отлично работает. Просто на данный момент я включил его в
>  kernel-image-led-tc, версию 0.3

Значит обновлений для kernel-source-compcache можно не ждать?

-- 
icesik

Re: [devel] obsoleted package

[Led]

Sunday, 30 March 2008 17:16:55 Igor Zubkov написав:
> 30.03.08, Led<ledest@gmail.com> написал(а):
> >  > L> Прошу отправить в obsolete пакет
> >  > L> kernel-modules-compc ache-led-tc
> >  >
> >  > Оно не заработало?
> >
> > По-моему, отлично работает. Просто на данный момент я включил его в
> >  kernel-image-led-tc, версию 0.3
>
> Значит обновлений для kernel-source-compcache можно не ждать?

Он кому-то кроме меня для kernel-image-led-tc нужен? Если нужен - обновлю.

-- 
Led

Re: [devel] obsoleted package

[Led]

Sunday, 30 March 2008 17:16:29 Led написав:
> Sunday, 30 March 2008 11:44:23 Konstantin A. Lepikhov написав:
> > Hi Led!
> >
> > Sunday 30, at 02:48:21 AM you wrote:
> > > Sunday, 30 March 2008 02:10:06 Денис Смирнов написав:
> > > > On Sat, Mar 29, 2008 at 08:44:34PM +0200, Led wrote:
> > > > L> Прошу отправить в obsolete пакет
> > > > L> kernel-modules-compc ache-led-tc
> > > >
> > > > Оно не заработало?
> > >
> > > По-моему, отлично работает. Просто на данный момент я включил его в
> > > kernel-image-led-tc, версию 0.3
> >
> > А ты можешь популярно объяснить, зачем kernel-image-led носит все с
> > собой?
>
> Навскидку - 3 субъективных момента:
> 1) мне так удобнее
> 2) удобнее обновлять в LTSP-чруте
> 3) не нужно руками перегенерировать initrd после установки ядра и
> необходимых Ethernet-модулей.
> Ко всему прочему, я так и не понял логику: почему пакет kernel-image-*
> таскает всё с собой (даже очень редко используемые модули), а те модули,
> которые используются на порядок чаще - в отдельных пакетах:)

В случае с compcache там ещё один момент:
он таскает с собой lzo1 (для совместимости со старыми ядрами, я же оторвал его 
и добавил в kernel-image-led-tc патч - бэкпорт lib/lzo1 из 2.6.24

-- 
Led

Re: [devel] kernel modules

[Dmitry V. Levin]

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

On Sun, Mar 30, 2008 at 05:16:29PM +0300, Led wrote:
[...]
> Ко всему прочему, я так и не понял логику: почему пакет kernel-image-* таскает 
> всё с собой (даже очень редко используемые модули), а те модули, которые 
> используются на порядок чаще - в отдельных пакетах:)

"Внешними модулями называются модули, [...]
которые собираются отдельно от ядра."

Это ещё в /usr/share/doc/kernel-build-tools-*/kernel-policy.txt было
написано.


-- 
ldv

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

Re: [devel] kernel modules

[Led]

Sunday, 30 March 2008 17:29:14 Dmitry V. Levin написав:
> On Sun, Mar 30, 2008 at 05:16:29PM +0300, Led wrote:
> [...]
>
> > Ко всему прочему, я так и не понял логику: почему пакет kernel-image-*
> > таскает всё с собой (даже очень редко используемые модули), а те модули,
> > которые используются на порядок чаще - в отдельных пакетах:)
>
> "Внешними модулями называются модули, [...]
> которые собираются отдельно от ядра."

Значит в моём случае cdfs, cloop, atl2, r8186, usbip, subfs, iscsitarget, 
compcache - это, по определению, не внешние, а "внутренние" модули:)

> Это ещё в /usr/share/doc/kernel-build-tools-*/kernel-policy.txt было
> написано.

-- 
Led

Re: [devel] obsoleted package

[Konstantin A. Lepikhov]

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

Hi Led!

Sunday 30, at 05:16:29 PM you wrote:

> Sunday, 30 March 2008 11:44:23 Konstantin A. Lepikhov написав:
> > Hi Led!
> >
> > Sunday 30, at 02:48:21 AM you wrote:
> > > Sunday, 30 March 2008 02:10:06 Денис Смирнов написав:
> > > > On Sat, Mar 29, 2008 at 08:44:34PM +0200, Led wrote:
> > > > L> Прошу отправить в obsolete пакет
> > > > L> kernel-modules-compc ache-led-tc
> > > >
> > > > Оно не заработало?
> > >
> > > По-моему, отлично работает. Просто на данный момент я включил его в
> > > kernel-image-led-tc, версию 0.3
> >
> > А ты можешь популярно объяснить, зачем kernel-image-led носит все с собой?
> 
> Навскидку - 3 субъективных момента:
> 1) мне так удобнее
> 2) удобнее обновлять в LTSP-чруте
> 3) не нужно руками перегенерировать initrd после установки ядра и необходимых 
> Ethernet-модулей.
> Ко всему прочему, я так и не понял логику: почему пакет kernel-image-* таскает 
> всё с собой (даже очень редко используемые модули), а те модули, которые 
> используются на порядок чаще - в отдельных пакетах:)
Что ж, больше вопросов не имею.

-- 
WBR et al.

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

Re: [devel] obsoleted package

[Konstantin A. Lepikhov]

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

Hi Led!

Sunday 30, at 05:16:29 PM you wrote:

...
> Ко всему прочему, я так и не понял логику: почему пакет kernel-image-* таскает 
> всё с собой (даже очень редко используемые модули), а те модули, которые 
> используются на порядок чаще - в отдельных пакетах:)
1) Потому мантейнерам было лень их отпиливать (максимум - modules-alsa и
modules-oss, хотя можно было бы и как убунты делают, net-modules и пакеты
по подсистемам). Ставить на рутер ядро + кучу ненужного барахла это
неинтересно.
2) Есть понятие "модули ядра", т.е, те, что поддерживает "ванильное" ядро,
и остальные модули. Вот как раз остальные должны жить отдельно, поскольку
сами по-себе являются факультативными.

Хотя, сейчас у нас разброд и шатание, думаю, скоро появятся и монолитные
ядра "со всем в пузе", потому что кому-то так удобно.

-- 
WBR et al.

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

Re: [devel] obsoleted package

[Igor Zubkov]

30.03.08, Led написал(а):
>  > >  > L> Прошу отправить в obsolete пакет
>  > >  > L> kernel-modules-compc ache-led-tc
>  > >  >
>  > >  > Оно не заработало?
>  > >
>  > > По-моему, отлично работает. Просто на данный момент я включил его в
>  > >  kernel-image-led-tc, версию 0.3
>  >
>  > Значит обновлений для kernel-source-compcache можно не ждать?
>
> Он кому-то кроме меня для kernel-image-led-tc нужен? Если нужен - обновлю.

Мне нужен. Так же было бы не плохо собрать этот модуль под все .24 ядра у нас.

-- 
icesik

Re: [devel] obsoleted package

[Led]

Sunday, 30 March 2008 17:49:05 Konstantin A. Lepikhov написав:
> Hi Led!
>
> Sunday 30, at 05:16:29 PM you wrote:
>
> ...
>
> > Ко всему прочему, я так и не понял логику: почему пакет kernel-image-*
> > таскает всё с собой (даже очень редко используемые модули), а те модули,
> > которые используются на порядок чаще - в отдельных пакетах:)
>
> 1) Потому мантейнерам было лень их отпиливать (максимум - modules-alsa и
> modules-oss, хотя можно было бы и как убунты делают, net-modules и пакеты
> по подсистемам). Ставить на рутер ядро + кучу ненужного барахла это
> неинтересно.

Ну вот и о том же: либо распилить ядро на наборы модулей, либо 
понятие "внешние модули" не имеет никакого практического смысла для 
пользователя.

> 2) Есть понятие "модули ядра", т.е, те, что поддерживает "ванильное" ядро,
> и остальные модули. Вот как раз остальные должны жить отдельно, поскольку
> сами по-себе являются факультативными.

Вот те "внешние" модули, которые я собираю с ядром, для kernel-image-led-tc 
являются как раз практически "нефакультативными".

Ну вот, как "обходить" 3-й пункт ты так и не сказал:)

>
> Хотя, сейчас у нас разброд и шатание, думаю, скоро появятся и монолитные
> ядра "со всем в пузе", потому что кому-то так удобно.

Как это не парадоксально, но в первую очередь это удобно пользователю 
(имеющему права и привычку регулярно обновлять ядро) при микроскопическом 
оверхеде по объёму (да, я знаю про всевозможные костыли-скрипты от разных 
авторов, которые "обновляют всё и красиво вместе с ядром", но от этого они 
перестают быть костылями). А по факту - ядра обновляются чаще, чем 
90% "внешних модулей", которые потом "догоняют" ядро в репозитарии в течении 
нескольких дней. Но "догоняют" только формально, потому как множество 
kernel-source-module остаются безнадёжно устаревшими по версиям :(

-- 
Led

Re: [devel] obsoleted package

[Led]

Sunday, 30 March 2008 17:54:39 Igor Zubkov написав:
> 30.03.08, Led написал(а):
> >  > >  > L> Прошу отправить в obsolete пакет
> >  > >  > L> kernel-modules-compc ache-led-tc
> >  > >  >
> >  > >  > Оно не заработало?
> >  > >
> >  > > По-моему, отлично работает. Просто на данный момент я включил его в
> >  > >  kernel-image-led-tc, версию 0.3
> >  >
> >  > Значит обновлений для kernel-source-compcache можно не ждать?
> >
> > Он кому-то кроме меня для kernel-image-led-tc нужен? Если нужен -
> > обновлю.
>
> Мне нужен. Так же было бы не плохо собрать этот модуль под все .24 ядра у
> нас.

К сожалению, экстрим с текущим сизифовскими 2.6.24 для меня "более 
экстримальный" и на порядок менее интересным, чем экстрим со самосборным 
2.6.25:)
Если хочешь, я могу перевесить kernel-source-compcache на тебя. Только отучи 
от его от сборки lzo* - в 2.6.24 есть свой lzo*

-- 
Led

Re: [devel] obsoleted package

[Konstantin A. Lepikhov]

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

Hi Led!

Sunday 30, at 06:07:11 PM you wrote:

> > 2) Есть понятие "модули ядра", т.е, те, что поддерживает "ванильное" ядро,
> > и остальные модули. Вот как раз остальные должны жить отдельно, поскольку
> > сами по-себе являются факультативными.
> 
> Вот те "внешние" модули, которые я собираю с ядром, для kernel-image-led-tc 
> являются как раз практически "нефакультативными".
Что мешает тебе сделать отдельное ядро + виртуальный пакет? Как минимум,
это даст экономию своего времени, поскольку избавит от рутины пересборки
"сторонних" модулей. Более того, наличие отдельного kernel-source - это
80% работы других мантейнеров для сборки этого модуля для своих ядер.
Подход "каждой кухарке - свое ядро" вреден тем, что как раз отбрасывает
все эти требования - теперь каждый собирает модули и ядра сам по себе, не
думая о других, что порождает все больше и больше бесплезных ядер,
различающихся только одним патчем/модулем в 2k.

> 
> Ну вот, как "обходить" 3-й пункт ты так и не сказал:)
> 
> >
> > Хотя, сейчас у нас разброд и шатание, думаю, скоро появятся и монолитные
> > ядра "со всем в пузе", потому что кому-то так удобно.
> 
> Как это не парадоксально, но в первую очередь это удобно пользователю 
> (имеющему права и привычку регулярно обновлять ядро) при микроскопическом 
Привычка обновлять ядро без причины - вредная привычка. И с ней неустанно
боролись :)

> оверхеде по объёму (да, я знаю про всевозможные костыли-скрипты от разных 
> авторов, которые "обновляют всё и красиво вместе с ядром", но от этого они 
> перестают быть костылями). А по факту - ядра обновляются чаще, чем 
> 90% "внешних модулей", которые потом "догоняют" ядро в репозитарии в течении 
> нескольких дней. Но "догоняют" только формально, потому как множество 
> kernel-source-module остаются безнадёжно устаревшими по версиям :(
Если собирать себе каждый день снапшоты из git, то да, модули будут
отставать по версиям. В других случаях описанная ситутация кажется мне
сильно надуманной. kernel-source у нас устаревают не потому, что ядро их
обгоняет, а потому что их собирать и чинить некому. 

-- 
WBR et al.

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

Re: [devel] obsoleted package

[Led]

Sunday, 30 March 2008 18:45:58 Konstantin A. Lepikhov написав:
> Hi Led!
>
> Sunday 30, at 06:07:11 PM you wrote:
> > > 2) Есть понятие "модули ядра", т.е, те, что поддерживает "ванильное"
> > > ядро, и остальные модули. Вот как раз остальные должны жить отдельно,
> > > поскольку сами по-себе являются факультативными.
> >
> > Вот те "внешние" модули, которые я собираю с ядром, для
> > kernel-image-led-tc являются как раз практически "нефакультативными".
>
> Что мешает тебе сделать отдельное ядро + виртуальный пакет?

Перманентно печальная судьбы наших kernel-complete отпугивает:) Хотя это тоже 
вариант решения. Но в случае с ltsp это опять же вносит дополнительные 
неоднозначности: в принципе, с ltsp можно использовать не только ядро led-tc, 
но другие ядра, а делать инструкцию "если вы используете led-tc, то делайте 
просто
apt-get install kernel-complete-led-tc
, а если другое ядро, то ... и т.д."

> Как минимум, 
> это даст экономию своего времени, поскольку избавит от рутины пересборки
> "сторонних" модулей. Более того, наличие отдельного kernel-source - это
> 80% работы других мантейнеров для сборки этого модуля для своих ядер.

С этим согласен (про 80%).

> Подход "каждой кухарке - свое ядро" вреден тем, что как раз отбрасывает
> все эти требования - теперь каждый собирает модули и ядра сам по себе, не
> думая о других, что порождает все больше и больше бесплезных ядер,
> различающихся только одним патчем/модулем в 2k.

А про причины возникновения ситуации "каждой кухарке - свое ядро" ты же 
знаешь?:)

>
> > Ну вот, как "обходить" 3-й пункт ты так и не сказал:)
> >
> > > Хотя, сейчас у нас разброд и шатание, думаю, скоро появятся и
> > > монолитные ядра "со всем в пузе", потому что кому-то так удобно.
> >
> > Как это не парадоксально, но в первую очередь это удобно пользователю
> > (имеющему права и привычку регулярно обновлять ядро) при микроскопическом
>
> Привычка обновлять ядро без причины - вредная привычка. И с ней неустанно
> боролись :)

Не передёргивай: есть ещё варианты (нередкие) "привычка обновлять ядро С 
ПРИЧИНОЙ":)

> > оверхеде по объёму (да, я знаю про всевозможные костыли-скрипты от разных
> > авторов, которые "обновляют всё и красиво вместе с ядром", но от этого
> > они перестают быть костылями). А по факту - ядра обновляются чаще, чем
> > 90% "внешних модулей", которые потом "догоняют" ядро в репозитарии в
> > течении нескольких дней. Но "догоняют" только формально, потому как
> > множество kernel-source-module остаются безнадёжно устаревшими по версиям
> > :(
>
> Если собирать себе каждый день снапшоты из git, то да, модули будут
> отставать по версиям.

Опять не передёргивай: я говорил о ВЕРСИЯХ, с вдумчивым прочтением ChangeLog'а 
(хотя в случае с drm имеет смысл смотреть и на "снапщоты git")

> В других случаях описанная ситутация кажется мне 
> сильно надуманной. kernel-source у нас устаревают не потому, что ядро их
> обгоняет, а потому что их собирать и чинить некому.

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

-- 
Led

Re: [devel] obsoleted package

[Konstantin A. Lepikhov]

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

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 + модули)?
Это будет непоодерживаемой конфигурацией?

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

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

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

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

-- 
WBR et al.

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

Re: [devel] obsoleted package

[Led]

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

Re: [devel] obsoleted package

[Konstantin A. Lepikhov]

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

Hi Led!

Sunday 30, at 07:46:28 PM you wrote:

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

> Перманентное игнорирование багзиллы, незамечание и "неприветствование"  
> готовых патчей и решений. Обид никаких, зато утвердившееся мнение, 
> что "спасение утопающих - дело рук самих утопающих".
> Основная же "фишка" led-tc - т.н. vm_deadlock-патчи. Они существовали 
> изначально только для >=2.6.21. После того как другие мои бэкпорты на 2.6.18 
> были проигнорированы, я даже не пытался портировать vm_deadlock на основное в 
> тот момент 2.6.18. На тот момент работоспособность ltsp5 в Сизифе 
> интересовала только меня и ещё пару человек, поэтому я понял, что всё нужно 
> делать самому: и ядро, и mkinitrd и т.п. Я потерял много времени пытаясь кого 
> в чём-то убеждить, но зато теперь точно знаю, что потерял это время зря и в 
> дальнейшем этого делать не буду:)
> Думаю, что остальные "кухарки" руководствовались схожими мотивами:)
в team было 2 человека, итак достаточно перегруженных
собственными проблемами и заботами. Более того, отстутствие железа,
мотивации и вопрос "а нафига мне это надо" ну никак не повышали
настроение. Да еще FUD от аналитиков и маркетоидов, которые ну никак не
могли понять, что документация в kernel-build-tools вполне себе
самодостаточна, и вполне может жить не как очередной опус на w.f.i., а как
вполне себе законченный guide (если конечно к нему добавить документацию
по git и пожить немного в ядерных списках рассылки). Насчет твоих патчей
уже озвучивал не раз список претензий - мне нужны коммиты, которые можно
мержить, а не стопка патчей, которые каждый раз нужно притирать. 100
патчей в ядро - это подход 5 летней давности, сейчас никто из вендоров так
не делает. Поскольку если ты с этим патчем пойдешь в апстрим, тебя
попросят git diff относительно HEAD, а не твоей локальной копии. Время -
деньги, а не сжигание себя в свободное от работы время.

> 
> > Я знаю, что текущее состояние с ядрами у нас настолько 
> > хреновое, что даже стыдно пользоваться каким-нибудь несобственным/неvsu
> > kernel-трам-пам-пам из сизифа ;)
> 
> Мне - не стыдно... просто - стрёмно:)
см. выше FUD - это страшая сила. Она погубила много сборщиков.

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

...
> > см. выше - иногда лучше прочитать, плюнуть и сделать свой -feat на текущее
> > ядро. Поскольку маленький кусок всегда лучше читается, чем 100Мб кода.
> 
> Я и сделал -feat'ы вместо устаревших "внешних модулей" - в чём тогда 
> заключаются твои притензии?
> 
см. выше - мне нужны коммиты. Или kernel-source. Все остальное - на свалку
истории.

-- 
WBR et al.

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

[devel] [JT] custom kernels, upstream merges, patches vs git, etc

[Michael Shigorin]

On Sun, Mar 30, 2008 at 09:08:20PM +0400, Konstantin A. Lepikhov wrote:
> > led-tc - это клиентское ядро, оно работает только на тонких
> > бездисковых клиентах.
> из названия это совершенно непонятно :)

1) ядра де-факто именные, посему led;
2) thin client довольно удобно сокращается до tc,
   при этом в %description есть уточнение:

The "tc" variant of kernel packages is a 2.6.x kernel configured
for use on diskless thin clients. Also it contains patches for
prevent deadlocks in swapping over network.

Или непонятно то, что на другой системе может быть другое ядро?
;)

[так... это лучше отдельным письмом; в основном угу]

> Время - деньги, а не сжигание себя в свободное от работы время.

Всё хуже, время -- даже не деньги.  Это ВРЕМЯ.

> см. выше FUD - это страшая сила. Она погубила много сборщиков.

Не совсем понял, при чём тут fear, uncertainity and doubt...

> > Пользователь "пинает" своего админа, а не мейнтейнера.
> мы говорим о пользователях сизифа. Пользователи дистрибутива -
> забота саппорта/внедренца.

Кость, речь о _кастомном_ ядре.  Саша может собирать его как
угодно -- другое дело, что взаимодействие по kernel-source или 
git trees действительно может сэкономить время, ну или у меня
тоже есть такая надежда.

Просто между идеальным на сейчас вариантом и "никаким" есть 
и другие градации.

> см. выше - мне нужны коммиты. Или kernel-source. Все остальное
> - на свалку истории.

Ну, эта, кто там говорил, что "менеджеры FUD разводят"?
По-моему, тут как раз ты преувеличиваешь насчёт смерти патчей ;)
(или всерьёз думаешь насчёт заняться мержем?  Peter Zijlstra,
думаю, тоже будет благодарен за помощь именно по этой части)

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

Re: [devel] obsoleted package

[Led]

Sunday, 30 March 2008 20:08:20 Konstantin A. Lepikhov написав:
> Hi Led!
>
> Sunday 30, at 07:46:28 PM you wrote:
> > led-tc - это клиентское ядро, оно работает только на тонких бездисковых
> > клиентах. Открою секрет: там даже smp не включен:) На сервере можно
> > использовать хоть std-smp, хоть std-ovz (у нас как раз серверная часть
> > ltsp в ovz-контейнере и крутится)
>
> из названия это совершенно непонятно :)
>
> > Перманентное игнорирование багзиллы, незамечание и "неприветствование"
> > готовых патчей и решений. Обид никаких, зато утвердившееся мнение,
> > что "спасение утопающих - дело рук самих утопающих".
> > Основная же "фишка" led-tc - т.н. vm_deadlock-патчи. Они существовали
> > изначально только для >=2.6.21. После того как другие мои бэкпорты на
> > 2.6.18 были проигнорированы, я даже не пытался портировать vm_deadlock на
> > основное в тот момент 2.6.18. На тот момент работоспособность ltsp5 в
> > Сизифе интересовала только меня и ещё пару человек, поэтому я понял, что
> > всё нужно делать самому: и ядро, и mkinitrd и т.п. Я потерял много
> > времени пытаясь кого в чём-то убеждить, но зато теперь точно знаю, что
> > потерял это время зря и в дальнейшем этого делать не буду:)
> > Думаю, что остальные "кухарки" руководствовались схожими мотивами:)
>
> в team было 2 человека, итак достаточно перегруженных
> собственными проблемами и заботами. Более того, отстутствие железа,
> мотивации и вопрос "а нафига мне это надо" ну никак не повышали
> настроение. Да еще FUD от аналитиков и маркетоидов, которые ну никак не
> могли понять, что документация в kernel-build-tools вполне себе
> самодостаточна, и вполне может жить не как очередной опус на w.f.i., а как
> вполне себе законченный guide (если конечно к нему добавить документацию
> по git и пожить немного в ядерных списках рассылки). Насчет твоих патчей
> уже озвучивал не раз список претензий - мне нужны коммиты, которые можно
> мержить, а не стопка патчей, которые каждый раз нужно притирать. 100
> патчей в ядро - это подход 5 летней давности, сейчас никто из вендоров так
> не делает. Поскольку если ты с этим патчем пойдешь в апстрим, тебя
> попросят git diff относительно HEAD, а не твоей локальной копии. Время -
> деньги, а не сжигание себя в свободное от работы время.
>
> > > Я знаю, что текущее состояние с ядрами у нас настолько
> > > хреновое, что даже стыдно пользоваться каким-нибудь несобственным/неvsu
> > > kernel-трам-пам-пам из сизифа ;)
> >
> > Мне - не стыдно... просто - стрёмно:)
>
> см. выше FUD - это страшая сила. Она погубила много сборщиков.
>
> > > > > Привычка обновлять ядро без причины - вредная привычка. И с ней
> > > > > неустанно боролись :)
> > > >
> > > > Не передёргивай: есть ещё варианты (нередкие) "привычка обновлять
> > > > ядро С ПРИЧИНОЙ":)
> > >
> > > А привычка бэкпортить что нравится не развита? Перенос вкусных фишек в
> > > -stable это как раз и есть работа мантейнера, а не мартышки, делающей
> > > git fetch из git.kernel.org и переносящей собранный тарболл в сизиф
> > > (пример с мартышкой отвлеченный ;) Более того, это не работа
> > > пользователя обновлять ядра, пользователь хочет функционал, пинает
> > > манейнера, который чешет репу и собирает ядро с заданным функционалом.
> >
> > Пользователь "пинает" своего админа, а не мейнтейнера.
>
> мы говорим о пользователях сизифа. Пользователи дистрибутива - забота
> саппорта/внедренца.
>
> ...
>
> > > см. выше - иногда лучше прочитать, плюнуть и сделать свой -feat на
> > > текущее ядро. Поскольку маленький кусок всегда лучше читается, чем
> > > 100Мб кода.
> >
> > Я и сделал -feat'ы вместо устаревших "внешних модулей" - в чём тогда
> > заключаются твои притензии?
>
> см. выше - мне нужны коммиты. Или kernel-source. Все остальное - на свалку
> истории.

А мне нужно кофе - в постель. Но чаще приходится самому вставать и готовить 
себе (при том, что всё уже практически готово, остаётся только смешать и 
закипятить):)
К тому же apt-get не умеет пока что устанавливать пакеты из git-репозитариев, 
а путь (по времени) от git до пакета в репозитарии - далеко не всегда один 
день и иногда растягиватся до бесконечности.

-- 
Led

Re: [devel] obsoleted package

[Konstantin A. Lepikhov]

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

Hi Led!

Sunday 30, at 08:40:38 PM you wrote:

<skip>
> > см. выше - мне нужны коммиты. Или kernel-source. Все остальное - на свалку
> > истории.
> 
> А мне нужно кофе - в постель. Но чаще приходится самому вставать и готовить 
> себе (при том, что всё уже практически готово, остаётся только смешать и 
> закипятить):)
Твой поход напоминает скорее разведение плантации кофе ради одной чашки.

> К тому же apt-get не умеет пока что устанавливать пакеты из git-репозитариев, 
> а путь (по времени) от git до пакета в репозитарии - далеко не всегда один 
> день и иногда растягиватся до бесконечности.
Как это ни странно, но и apt-get скоро не будет нужен вместе с
репозиторием :) Система связанных git repo'ов + backend для выдачи пакетов
"на сторону" вполне его заменяет. 

-- 
WBR et al.

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

Re: [devel] obsoleted package

[Led]

Sunday, 30 March 2008 21:42:12 Konstantin A. Lepikhov написав:
> Hi Led!
>
> Sunday 30, at 08:40:38 PM you wrote:
>
> <skip>
>
> > > см. выше - мне нужны коммиты. Или kernel-source. Все остальное - на
> > > свалку истории.
> >
> > А мне нужно кофе - в постель. Но чаще приходится самому вставать и
> > готовить себе (при том, что всё уже практически готово, остаётся только
> > смешать и закипятить):)
>
> Твой поход напоминает скорее разведение плантации кофе ради одной чашки.

Может быть. Я же сказал, что на тот момент это было нужно только мне и ещё 
пару человек:)

> > К тому же apt-get не умеет пока что устанавливать пакеты из
> > git-репозитариев, а путь (по времени) от git до пакета в репозитарии -
> > далеко не всегда один день и иногда растягиватся до бесконечности.
>
> Как это ни странно, но и apt-get скоро не будет нужен вместе с
> репозиторием :) Система связанных git repo'ов + backend для выдачи пакетов
> "на сторону" вполне его заменяет.

Извини, но я не очень-то верю проповедям и проповедникам. Я вижу только то, 
что после введения прогрессивной схемы сборки ядер (через git, а не так 
как "ни один вендор уже не делает") ситуация с ядрами в сизифе, мягко говоря, 
не улучшилась, а значительно ухудшилась (и это ТВОИ слова). Можно сколько 
угодно и как угодно фанатично верить, что это не связано, но факт 
совпадения(?) - налицо.
Как и что "будет" можно говорить много, но, сорри, я не хочу об этом 
говорить - я ничего в этом не решаю. Когда это "светлое будущее" наступит - 
тогда будет о чём говорить.

-- 
Led

Re: [devel] obsoleted package

[Konstantin A. Lepikhov]

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

Hi Led!

Sunday 30, at 10:11:34 PM you wrote:

<skip>
> > Как это ни странно, но и apt-get скоро не будет нужен вместе с
> > репозиторием :) Система связанных git repo'ов + backend для выдачи пакетов
> > "на сторону" вполне его заменяет.
> 
> Извини, но я не очень-то верю проповедям и проповедникам. Я вижу только то, 
> что после введения прогрессивной схемы сборки ядер (через git, а не так 
> как "ни один вендор уже не делает") ситуация с ядрами в сизифе, мягко говоря, 
> не улучшилась, а значительно ухудшилась (и это ТВОИ слова). Можно сколько 
> угодно и как угодно фанатично верить, что это не связано, но факт 
> совпадения(?) - налицо.
Не надо искажать мои слова - я не говорил, что переход на git ухучшил ядра
в сизифе. Текущее состояние с ядрами - дело рук некоторых людей, которые
почему-то решили что они самые умные и что раз они такие умные то можно
упразднить старые правила и KMT. И эта заслуга еще и тех, кто кричал "ах
какая мудрая у нас схема, нихера не понимаю и разбираться не хочу".

> Как и что "будет" можно говорить много, но, сорри, я не хочу об этом 
> говорить - я ничего в этом не решаю. Когда это "светлое будущее" наступит - 
> тогда будет о чём говорить.
если о светлом будущем только и говорить, то он никогда не наступит. Лучше
начать с себя.

-- 
WBR et al.

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

Re: [devel] obsoleted package

[Led]

Sunday, 30 March 2008 22:38:00 Konstantin A. Lepikhov написав:
> Hi Led!
>
> Sunday 30, at 10:11:34 PM you wrote:
>
> <skip>
>
> > > Как это ни странно, но и apt-get скоро не будет нужен вместе с
> > > репозиторием :) Система связанных git repo'ов + backend для выдачи
> > > пакетов "на сторону" вполне его заменяет.
> >
> > Извини, но я не очень-то верю проповедям и проповедникам. Я вижу только
> > то, что после введения прогрессивной схемы сборки ядер (через git, а не
> > так как "ни один вендор уже не делает") ситуация с ядрами в сизифе, мягко
> > говоря, не улучшилась, а значительно ухудшилась (и это ТВОИ слова). Можно
> > сколько угодно и как угодно фанатично верить, что это не связано, но факт
> > совпадения(?) - налицо.
>
> Не надо искажать мои слова - я не говорил, что переход на git ухучшил ядра
> в сизифе.

Я тоже ТАК не говорил. Просто так почему-то, к сожалению, совпало :( 

> Текущее состояние с ядрами - дело рук некоторых людей, которые 
> почему-то решили что они самые умные и что раз они такие умные то можно
> упразднить старые правила и KMT. И эта заслуга еще и тех, кто кричал "ах
> какая мудрая у нас схема, нихера не понимаю и разбираться не хочу".
>
> > Как и что "будет" можно говорить много, но, сорри, я не хочу об этом
> > говорить - я ничего в этом не решаю. Когда это "светлое будущее" наступит
> > - тогда будет о чём говорить.
>
> если о светлом будущем только и говорить, то он никогда не наступит. Лучше
> начать с себя.

"Начинание с себя" у нас обычно называют "кухаркиными потугами":)

-- 
Led

Re: [devel] obsoleted package

[Eugene Ostapets]

30.03.08, Konstantin A. Lepikhov<lakostis altlinux.org> написал(а):
> Hi Led!
> 1) Потому мантейнерам было лень их отпиливать (максимум - modules-alsa и
>  modules-oss, хотя можно было бы и как убунты делают, net-modules и пакеты
>  по подсистемам). Ставить на рутер ядро + кучу ненужного барахла это
>  неинтересно.
Вот только не надо про убунту, у них новоя ядро накатывается по
apt-get upgrade, а не как у нас... Поэтому, чем монолитнее пакет с
ядром - тем проще обычным пользователям его обновнять...
-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] obsoleted package

[Mikhail Gusarov]

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

Twas brillig at 09:49:33 31.03.2008 UTC+03 when Eugene Ostapets did gyre and gimble:

 EO> Поэтому, чем монолитнее пакет с ядром - тем проще обычным
 EO> пользователям его обновнять...

Только при прочих равных. Какой-нибудь хитрый трюк с RPM-ными
зависимостями этот недостаток рубленых ядер может
скомпенсировать. Правда, вопрос отставания модулей по версиям всё равно
останется.

-- 

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

Re: [devel] obsoleted package

[Eugene Ostapets]

31.03.08, Mikhail Gusarov<dottedmag dottedmag.net> написал(а):
> Twas brillig at 09:49:33 31.03.2008 UTC+03 when Eugene Ostapets did gyre and gimble:
>
>   EO> Поэтому, чем монолитнее пакет с ядром - тем проще обычным
>   EO> пользователям его обновнять...
>
>  Только при прочих равных. Какой-нибудь хитрый трюк с RPM-ными
>  зависимостями этот недостаток рубленых ядер может
>  скомпенсировать. Правда, вопрос отставания модулей по версиям всё равно
>  останется.
Хитрый трюк имени kernel-modules-complete у нас был когда-то... Помер...

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] obsoleted package

[Mikhail Gusarov]

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

Twas brillig at 09:54:18 31.03.2008 UTC+03 when Eugene Ostapets did gyre and gimble:

 EO> Хитрый трюк имени kernel-modules-complete у нас был
 EO> когда-то... Помер...

Оказался нежизнеспособен или просто захирел от отсутствия внимания?

-- 

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

Re: [devel] obsoleted package

[Eugene Ostapets]

2008/3/31, Mikhail Gusarov <dottedmag@dottedmag.net>:
> Twas brillig at 09:54:18 31.03.2008 UTC+03 when Eugene Ostapets did gyre and gimble:
>
>   EO> Хитрый трюк имени kernel-modules-complete у нас был
>   EO> когда-то... Помер...
>
>  Оказался нежизнеспособен или просто захирел от отсутствия внимания?
1. Пугал простых пользователей, когда им рекомендовали снести какой-то
модуль ядра, а апт говорил, что снесет kernel-modules-complete
2. При добавлении/удалении модулей майнтейнер забывал/не успевал
обновлять информацию в пакете
-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] obsoleted package

[Michael Shigorin]

On Mon, Mar 31, 2008 at 09:49:33AM +0300, Eugene Ostapets wrote:
> Вот только не надо про убунту, у них новоя ядро накатывается по
> apt-get upgrade, а не как у нас... Поэтому, чем монолитнее
> пакет с ядром - тем проще обычным пользователям его
> обновнять...

У нас завёлся пакет update-kernel.

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

Re: [devel] obsoleted package

[Eugene Ostapets]

31.03.08, Michael Shigorin<mike osdn.org.ua> написал(а):
> On Mon, Mar 31, 2008 at 09:49:33AM +0300, Eugene Ostapets wrote:
>  > Вот только не надо про убунту, у них новоя ядро накатывается по
>  > apt-get upgrade, а не как у нас... Поэтому, чем монолитнее
>  > пакет с ядром - тем проще обычным пользователям его
>  > обновнять...
> У нас завёлся пакет update-kernel.
В каком дистрибутиве он завелся? Ах, мы про Сизиф? Ну так большинство
пользователей Сизифа и без этого пакета справляются с обновлением
ядра... Но тем не менее, абсолютно не понятно, как можно поддерживать
массовые установки дистрибутива у низкоквалифицированных
пользователей, если обновление ядра будет требовать шаманских плясок в
консоли... Да, да - я о школьном дистрибутиве...

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] update-kernel

[Led]

В сообщении от Monday 31 March 2008 16:01:21 Michael Shigorin написал(а):
> On Mon, Mar 31, 2008 at 07:55:33PM +0700, Mikhail Gusarov wrote:
> >  >> Да, да - я о школьном дистрибутиве...
> >
> >  MS> Ну в Линукс Терминал я его сам положу.
> > Всё равно это паллиатив, а не решение. В интерфейсе synaptic
> > его нет, так что это geek-only.
>
> Стопроцентное решение приветствуется ;)
>
> С точки зрения суппортабельности сказать "наберите update-kernel
> в терминале" всё равно сильно проще, чем расписывать всё полотно.

/sbin/installkernel после фактической установки последнего модуля он тебе тоже 
вызовет?

-- 
Led

[devel] update-kernel

[Michael Shigorin]

On Mon, Mar 31, 2008 at 02:43:50PM +0300, Eugene Ostapets wrote:
> > У нас завёлся пакет update-kernel.
> В каком дистрибутиве он завелся? Ах, мы про Сизиф?

И про бранч.

> Да, да - я о школьном дистрибутиве...

Ну в Линукс Терминал я его сам положу.

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

Re: [devel] update-kernel

[Mikhail Gusarov]

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

Twas brillig at 15:53:09 31.03.2008 UTC+03 when Michael Shigorin did gyre and gimble:

 >> Да, да - я о школьном дистрибутиве...
 MS> Ну в Линукс Терминал я его сам положу.

Всё равно это паллиатив, а не решение. В интерфейсе synaptic его нет,
так что это geek-only.

-- 

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

Re: [devel] update-kernel

[Michael Shigorin]

On Mon, Mar 31, 2008 at 07:55:33PM +0700, Mikhail Gusarov wrote:
>  >> Да, да - я о школьном дистрибутиве...
>  MS> Ну в Линукс Терминал я его сам положу.
> Всё равно это паллиатив, а не решение. В интерфейсе synaptic
> его нет, так что это geek-only.

Стопроцентное решение приветствуется ;)

С точки зрения суппортабельности сказать "наберите update-kernel
в терминале" всё равно сильно проще, чем расписывать всё полотно.

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

Re: [devel] update-kernel

[Anton Farygin]

Michael Shigorin пишет:
> On Mon, Mar 31, 2008 at 07:55:33PM +0700, Mikhail Gusarov wrote:
>>  >> Да, да - я о школьном дистрибутиве...
>>  MS> Ну в Линукс Терминал я его сам положу.
>> Всё равно это паллиатив, а не решение. В интерфейсе synaptic
>> его нет, так что это geek-only.
> 
> Стопроцентное решение приветствуется ;)
> 
> С точки зрения суппортабельности сказать "наберите update-kernel
> в терминале" всё равно сильно проще, чем расписывать всё полотно.

Миша, есть идея как это сделать, но нет времени на реализацию.

Можно (теоретически) попробовать написать на lua скрипт к apt'у, что бы 
он вытаскивал список уже установленных kernel-modules и формировал новый 
для upgrade.

Re: [devel] update-kernel

[Michael Shigorin]

On Mon, Mar 31, 2008 at 05:21:53PM +0400, Anton Farygin wrote:
> >>Всё равно это паллиатив, а не решение. В интерфейсе synaptic
> >>его нет, так что это geek-only.
> >Стопроцентное решение приветствуется ;)
> Миша, есть идея как это сделать, но нет времени на реализацию.
> Можно (теоретически) попробовать написать на lua скрипт к
> apt'у, что бы он вытаскивал список уже установленных
> kernel-modules и формировал новый для upgrade.

Мне слабо (собственно, и шелловый скриптик пока раскачивался --
уже Виталик написал).  Там почему объехать изменения в списке
получается -- не одной транзакцией устанавливается.  Ну исчез
kernel-modules-zuzu, ну и ладно.


On Mon, Mar 31, 2008 at 03:11:36PM +0300, Led wrote:
> > С точки зрения суппортабельности сказать "наберите update-kernel
> > в терминале" всё равно сильно проще, чем расписывать всё полотно.
> /sbin/installkernel после фактической установки последнего
> модуля он тебе тоже вызовет?

Пока весь сторадж в kernel-image, там это не требуется.

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

Re: [devel] update-kernel

[Eugene Ostapets]

31.03.08, Michael Shigorin<mike osdn.org.ua> написал(а):
>  On Mon, Mar 31, 2008 at 03:11:36PM +0300, Led wrote:
>  > > С точки зрения суппортабельности сказать "наберите update-kernel
>  > > в терминале" всё равно сильно проще, чем расписывать всё полотно.
>
> > /sbin/installkernel после фактической установки последнего
>  > модуля он тебе тоже вызовет?
>
>
> Пока весь сторадж в kernel-image, там это не требуется.
Так мы же начали с предложения сделать "как в бубунте", разрезав
монолитник kernel-image на части по интересам:)

С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] update-kernel

[Michael Shigorin]

On Mon, Mar 31, 2008 at 04:55:44PM +0300, Eugene Ostapets wrote:
> >  > > С точки зрения суппортабельности сказать "наберите
> >  > > update-kernel в терминале" всё равно сильно проще, чем
> >  > > расписывать всё полотно.
> > > /sbin/installkernel после фактической установки последнего
> >  > модуля он тебе тоже вызовет?
> > Пока весь сторадж в kernel-image, там это не требуется.
> Так мы же начали с предложения сделать "как в бубунте",
> разрезав монолитник kernel-image на части по интересам:)

Погоди, мухи отдельно, котлеты отдельно.  А нечто такое я nidd@
предлагал года четыре ещё тому, но потом более внимательно
посидел с du(1) и понял, что внятного предложения по осмысленной
порезке предложить не смогу.

А вот почему у нас модули не gzip'аются -- то ли так и не понял,
то ли опять забыл.

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

Re: [devel] update-kernel

[Anton Farygin]

Michael Shigorin пишет:
> On Mon, Mar 31, 2008 at 04:55:44PM +0300, Eugene Ostapets wrote:
>>>  > > С точки зрения суппортабельности сказать "наберите
>>>  > > update-kernel в терминале" всё равно сильно проще, чем
>>>  > > расписывать всё полотно.
>>>> /sbin/installkernel после фактической установки последнего
>>>  > модуля он тебе тоже вызовет?
>>> Пока весь сторадж в kernel-image, там это не требуется.
>> Так мы же начали с предложения сделать "как в бубунте",
>> разрезав монолитник kernel-image на части по интересам:)
> 
> Погоди, мухи отдельно, котлеты отдельно.  А нечто такое я nidd@
> предлагал года четыре ещё тому, но потом более внимательно
> посидел с du(1) и понял, что внятного предложения по осмысленной
> порезке предложить не смогу.
> 
> А вот почему у нас модули не gzip'аются -- то ли так и не понял,
> то ли опять забыл.

Потому что gzip'ать модули не имеет смысла. Если места не хватает - то 
это какой-то embedded. А загрузка идёт ощутимо дольше с пожатыми модулями.

Re: [devel] obsoleted package

[Vladimir V. Kamarzin]

>>>>> On 31 Mar 2008 at 17:31 "MS" == Michael Shigorin writes:

>> Вот только не надо про убунту, у них новоя ядро накатывается по
>> apt-get upgrade, а не как у нас... Поэтому, чем монолитнее
>> пакет с ядром - тем проще обычным пользователям его
>> обновнять...

MS> У нас завёлся пакет update-kernel.

Чтобы рекомендовать его к использованию, нужно сначала отцепить rpmvercmp от
rpm-utils, потому что оно тащит за собой rpm-build, который не нужен ни на
сервере, ни на машине рядового пользователя.

Бага висит, реакции нет.

-- 
vvk

Re: [devel] obsoleted package

[Michael Shigorin]

On Tue, Apr 01, 2008 at 10:52:41AM +0600, Vladimir V. Kamarzin wrote:
> >> Вот только не надо про убунту, у них новоя ядро накатывается
> >> по apt-get upgrade, а не как у нас... Поэтому, чем
> >> монолитнее пакет с ядром - тем проще обычным пользователям
> >> его обновнять...
> MS> У нас завёлся пакет update-kernel.
> Чтобы рекомендовать его к использованию, нужно сначала отцепить
> rpmvercmp от rpm-utils, потому что оно тащит за собой
> rpm-build, который не нужен ни на сервере, ни на машине
> рядового пользователя.  Бага висит, реакции нет.

Мож выдрать в отдельный RPMvercmp? ;-)

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

Re: [devel] obsoleted package

[Хихин Руслан]

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

Здравствуйте Eugene Ostapets
  В сообщении от 31 марта 2008 Eugene Ostapets написал(a):
 >  Но тем не менее, абсолютно не понятно, как можно поддерживать
 > массовые установки дистрибутива у низкоквалифицированных
 > пользователей, если обновление ядра будет требовать шаманских плясок
 > в
 > консоли... Да, да - я о школьном дистрибутиве...
А там вроде обновление ядра и не планируется. 
Только вместе с дистрибутивом. Но это уже проблема будущего 
дитстрибутива на основе Мастер 4.1 и т.п.
Или я не в курсе ? 


-- 
С  уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]