[devel] Q: update kernel-policy

[devel] Q: update kernel-policy

[Dmitry V. Levin]

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

Hi,

В связи с очередными попытками нарушения устного соглашения, напр.,
---
Пакет dvb-tools версии 20031013-alt1 имеет неудовлетворенные зависимости:
 Для установки требует: kernel-modules-dvb (= 2003-10-13)
---
предлагаю формализовать требования к зависимостям пакетов, содержащих код,
исполняющийся в контексте ядра (т.е. kernel-image-XXX и
kernel-modules-XXX):

1. Никакие пакеты, кроме пакетов вида kernel-modules-XXX и
kernel-сomplete-XXX, не могут иметь зависимости на пакеты вида
kernel-image-XXX и kernel-modules-XXX.

2. Каждый пакет вида kernel-modules-XXX должен иметь одну и только одну
зависимость вида kernel-image-XXX.


Прошу заинтересованных прокомментировать.


-- 
ldv

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

Re: [devel] Q: update kernel-policy

[Вячеслав Диконов]

В Срд, 21.01.2004, в 19:40, Dmitry V. Levin пишет:
> Hi,
> 
> В связи с очередными попытками нарушения устного соглашения, напр.,
> ---
> Пакет dvb-tools версии 20031013-alt1 имеет неудовлетворенные зависимости:
>  Для установки требует: kernel-modules-dvb (= 2003-10-13)
И это правильно! Программки в этом пакете суть составная часть пакета
драйверов и без своих модулей абсолютно бесполезны. Более того, их
работа с другой версией модулей тоже не гарантируется!

> ---
> предлагаю формализовать требования к зависимостям пакетов, содержащих код,
> исполняющийся в контексте ядра (т.е. kernel-image-XXX и
> kernel-modules-XXX):
> 
> 1. Никакие пакеты, кроме пакетов вида kernel-modules-XXX и
> kernel-сomplete-XXX, не могут иметь зависимости на пакеты вида
> kernel-image-XXX и kernel-modules-XXX.
А как быть с приложениями зависящими от конкретных драйверов (модулей) и
в принципе не могущих работать без них? Мой пример - VDR (я его уже в
целом собрал, локализовал и тестирую). Такая зависимость позволит:

1) воткнуть DVB карту и антенну;
2) указать в синаптике пакет vdr или xawtv-vdr и сразу получить
полностью рабочую систему для приёма цифрового ТВ со всеми драйверами и
сопутствующими примочками.  

Поиск ответов типа "чего же мне ещё надо, то?" может занять у новичка
много дней и надо ещё догадаться, что VDR работает только с драйверами
карт SS с linuxtv, и что kernel-modules-dvb и есть то, что ему надо.


> 2. Каждый пакет вида kernel-modules-XXX должен иметь одну и только одну
> зависимость вида kernel-image-XXX.
Разумно.
> Прошу заинтересованных прокомментировать.

Re: [devel] Q: update kernel-policy

[Вячеслав Диконов]

В Срд, 21.01.2004, в 19:40, Dmitry V. Levin пишет:
> Hi,
> 
> В связи с очередными попытками нарушения устного соглашения, напр.,
> ---
> Пакет dvb-tools версии 20031013-alt1 имеет неудовлетворенные зависимости:
>  Для установки требует: kernel-modules-dvb (= 2003-10-13)
И это правильно! Программки в этом пакете суть составная часть пакета
драйверов и без своих модулей абсолютно бесполезны. Более того, их
работа с другой версией модулей тоже не гарантируется!

> ---
> предлагаю формализовать требования к зависимостям пакетов, содержащих код,
> исполняющийся в контексте ядра (т.е. kernel-image-XXX и
> kernel-modules-XXX):
> 
> 1. Никакие пакеты, кроме пакетов вида kernel-modules-XXX и
> kernel-сomplete-XXX, не могут иметь зависимости на пакеты вида
> kernel-image-XXX и kernel-modules-XXX.
А как быть с приложениями зависящими от конкретных драйверов (модулей) и
в принципе не могущих работать без них? Мой пример - VDR (я его уже в
целом собрал, локализовал и тестирую). Такая зависимость позволит:

1) воткнуть DVB карту и антенну;
2) указать в синаптике пакет vdr или xawtv-vdr и сразу получить
полностью рабочую систему для приёма цифрового ТВ со всеми драйверами и
сопутствующими примочками.  

Поиск ответов типа "чего же мне ещё надо, то?" может занять у новичка
много дней и надо ещё догадаться, что VDR работает только с драйверами
карт SS с linuxtv, и что kernel-modules-dvb и есть то, что ему надо.


> 2. Каждый пакет вида kernel-modules-XXX должен иметь одну и только одну
> зависимость вида kernel-image-XXX.
Разумно.
> Прошу заинтересованных прокомментировать.

Re: [devel] Q: update kernel-policy

[Вячеслав Диконов]

В Срд, 21.01.2004, в 19:40, Dmitry V. Levin пишет:
> Hi,
> 
> В связи с очередными попытками нарушения устного соглашения, напр.,
> ---
> Пакет dvb-tools версии 20031013-alt1 имеет неудовлетворенные зависимости:
>  Для установки требует: kernel-modules-dvb (= 2003-10-13)
И это правильно! Программки в этом пакете суть составная часть пакета
драйверов и без своих модулей абсолютно бесполезны. Более того, их
работа с другой версией модулей тоже не гарантируется!

> ---
> предлагаю формализовать требования к зависимостям пакетов, содержащих код,
> исполняющийся в контексте ядра (т.е. kernel-image-XXX и
> kernel-modules-XXX):
> 
> 1. Никакие пакеты, кроме пакетов вида kernel-modules-XXX и
> kernel-сomplete-XXX, не могут иметь зависимости на пакеты вида
> kernel-image-XXX и kernel-modules-XXX.
А как быть с приложениями зависящими от конкретных драйверов (модулей) и
в принципе не могущих работать без них? Мой пример - VDR (я его уже в
целом собрал, локализовал и тестирую). Такая зависимость позволит:

1) воткнуть DVB карту и антенну;
2) указать в синаптике пакет vdr или xawtv-vdr и сразу получить
полностью рабочую систему для приёма цифрового ТВ со всеми драйверами и
сопутствующими примочками.  

Поиск ответов типа "чего же мне ещё надо, то?" может занять у новичка
много дней и надо ещё догадаться, что VDR работает только с драйверами
карт SS с linuxtv, и что kernel-modules-dvb и есть то, что ему надо.


> 2. Каждый пакет вида kernel-modules-XXX должен иметь одну и только одну
> зависимость вида kernel-image-XXX.
Разумно.
> Прошу заинтересованных прокомментировать.

Re: [devel] Q: update kernel-policy

[Denis Ovsienko]

> 1. Никакие пакеты, кроме пакетов вида kernel-modules-XXX и
> kernel-сomplete-XXX, не могут иметь зависимости на пакеты вида
> kernel-image-XXX и kernel-modules-XXX.
Почему же? В модулях может быть какое-то API, без которого userspace
пакет будет бесполезным. Или в ядре. Я уже который раз прошу
промаркировать соответствующие ядра как cryptoapi-kernel, но меня
игнорируют, поэтому что остаётся делать?


> 2. Каждый пакет вида kernel-modules-XXX должен иметь одну и только одну
> зависимость вида kernel-image-XXX.
Да. Потому что их много.

--
    DO4-UANIC

Re: [devel] Q: update kernel-policy

[Anton Farygin]

On Wed, Jan 21, 2004 at 09:58:04PM +0300, Вячеслав Диконов wrote:
> В Срд, 21.01.2004, в 19:40, Dmitry V. Levin пишет:
> > Hi,
> > 
> > В связи с очередными попытками нарушения устного соглашения, напр.,
> > ---
> > Пакет dvb-tools версии 20031013-alt1 имеет неудовлетворенные зависимости:
> >  Для установки требует: kernel-modules-dvb (= 2003-10-13)
> И это правильно! Программки в этом пакете суть составная часть пакета
> драйверов и без своих модулей абсолютно бесполезны. Более того, их
> работа с другой версией модулей тоже не гарантируется!

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

> 
> > ---
> > предлагаю формализовать требования к зависимостям пакетов, содержащих код,
> > исполняющийся в контексте ядра (т.е. kernel-image-XXX и
> > kernel-modules-XXX):
> > 
> > 1. Никакие пакеты, кроме пакетов вида kernel-modules-XXX и
> > kernel-сomplete-XXX, не могут иметь зависимости на пакеты вида
> > kernel-image-XXX и kernel-modules-XXX.
> А как быть с приложениями зависящими от конкретных драйверов (модулей) и
> в принципе не могущих работать без них? Мой пример - VDR (я его уже в
> целом собрал, локализовал и тестирую). Такая зависимость позволит:
> 
> 1) воткнуть DVB карту и антенну;
> 2) указать в синаптике пакет vdr или xawtv-vdr и сразу получить
> полностью рабочую систему для приёма цифрового ТВ со всеми драйверами и
> сопутствующими примочками.  
> 
> Поиск ответов типа "чего же мне ещё надо, то?" может занять у новичка
> много дней и надо ещё догадаться, что VDR работает только с драйверами
> карт SS с linuxtv, и что kernel-modules-dvb и есть то, что ему надо.

А откуда твой Synaptic будет знать, что нужно именно этот драйвер именно
для этого ядра ?

А если у пользователя другое ядро ? (другой версии)
> 
> 
> > 2. Каждый пакет вида kernel-modules-XXX должен иметь одну и только одну
> > зависимость вида kernel-image-XXX.
> Разумно.
> > Прошу заинтересованных прокомментировать.
> 
> 
> _______________________________________________
> Devel mailing list
> Devel@altlinux.ru
> http://altlinux.ru/mailman/listinfo/devel

Re: [d-kernel] Re: [devel] Q: update kernel-policy

[Anton Farygin]

On Thu, Jan 22, 2004 at 06:24:49AM +0200, Denis Ovsienko wrote:
> 
> > 1. Никакие пакеты, кроме пакетов вида kernel-modules-XXX и
> > kernel-сomplete-XXX, не могут иметь зависимости на пакеты вида
> > kernel-image-XXX и kernel-modules-XXX.
> Почему же? В модулях может быть какое-то API, без которого userspace
> пакет будет бесполезным. Или в ядре. Я уже который раз прошу
> промаркировать соответствующие ядра как cryptoapi-kernel, но меня
> игнорируют, поэтому что остаётся делать?

Пока не понятно, как привязывать userspace к kernelspace, ибо пакетов с
ядрами может стоять _огромное количество_, а реальное ядро - совсем не
совпадать с тем, что установлено.

> 
> 
> > 2. Каждый пакет вида kernel-modules-XXX должен иметь одну и только одну
> > зависимость вида kernel-image-XXX.
> Да. Потому что их много.

При чем kernel-modules-XXX должен иметь зависимость на kernel-image-XXX =
version-release

Rgds,
Rider

Re: [devel] Q: update kernel-policy

[Aleksey Avdeev]

Здравствуйте.

   Добавлю и свои 5 копеек (в плане драйверов ixpio - меня 
здорово интересует данная тема).

Anton Farygin пишет:
> On Wed, Jan 21, 2004 at 09:58:04PM +0300, Вячеслав Диконов wrote:
> 
>>В Срд, 21.01.2004, в 19:40, Dmitry V. Levin пишет:
>>
>>>Hi,
>>>
>>>В связи с очередными попытками нарушения устного соглашения, напр.,
>>>---
>>>Пакет dvb-tools версии 20031013-alt1 имеет неудовлетворенные зависимости:
>>> Для установки требует: kernel-modules-dvb (= 2003-10-13)
>>
>>И это правильно! Программки в этом пакете суть составная часть пакета
>>драйверов и без своих модулей абсолютно бесполезны. Более того, их
>>работа с другой версией модулей тоже не гарантируется!
> 
> 
> Хех. А как быть тогда в том случае, если пакет у меня стоит, но загружен я
> в другое ядро... 

   Если я правильно понимаю, то в случаи прописанной зависимости:

1. Нет нужного ядра: нет пакета (откажется ставится или будет 
вынесен вместе с ядром)

2. Ядро есть, но в данный момент не загружено: программы пакета 
(или система) будут сообщать о ошибках.

   Если всё работает нормально и (пользователь не 
разработчик/экспериментатор) то ситуация 1 болие часта (ИМХО). 
Если пользователь _сознательно_ попал в ситуацию 2 - значит его 
квалификации хватит для решения данной проблемы (или он так 
считает ;-)).

   Если примем предлагаемое изменение в политике - пользователь 
всегда будет в ситуации 2, независимо от его 
действий/квалификации. Оно нам надо?


> 
>>>---
>>>предлагаю формализовать требования к зависимостям пакетов, содержащих код,
>>>исполняющийся в контексте ядра (т.е. kernel-image-XXX и
>>>kernel-modules-XXX):
>>>
>>>1. Никакие пакеты, кроме пакетов вида kernel-modules-XXX и
>>>kernel-сomplete-XXX, не могут иметь зависимости на пакеты вида
>>>kernel-image-XXX и kernel-modules-XXX.
>>
>>А как быть с приложениями зависящими от конкретных драйверов (модулей) и
>>в принципе не могущих работать без них? Мой пример - VDR (я его уже в
>>целом собрал, локализовал и тестирую). Такая зависимость позволит:
>>
>>1) воткнуть DVB карту и антенну;
>>2) указать в синаптике пакет vdr или xawtv-vdr и сразу получить
>>полностью рабочую систему для приёма цифрового ТВ со всеми драйверами и
>>сопутствующими примочками.  
>>
>>Поиск ответов типа "чего же мне ещё надо, то?" может занять у новичка
>>много дней и надо ещё догадаться, что VDR работает только с драйверами
>>карт SS с linuxtv, и что kernel-modules-dvb и есть то, что ему надо.
> 
> 
> А откуда твой Synaptic будет знать, что нужно именно этот драйвер именно
> для этого ядра ?
> 
> А если у пользователя другое ядро ? (другой версии)
> 
>>
>>>2. Каждый пакет вида kernel-modules-XXX должен иметь одну и только одну
>>>зависимость вида kernel-image-XXX.
>>
>>Разумно.
>>
>>>Прошу заинтересованных прокомментировать.

-- 

С уважением. Алексей.

Re: [devel] Q: update kernel-policy

[Ed V. Bartosh]

>>>>> "DO" == Denis Ovsienko writes:

 >>   1. Никакие пакеты, кроме пакетов вида kernel-modules-XXX и
 >>  kernel-сomplete-XXX, не могут иметь зависимости на пакеты вида
 >>  kernel-image-XXX и kernel-modules-XXX.
 DO>  Почему же? В модулях может быть какое-то API, без которого
 DO>  userspace пакет будет бесполезным. Или в ядре. Я уже который раз
 DO>  прошу промаркировать соответствующие ядра как cryptoapi-kernel,
 DO>  но меня игнорируют, поэтому что остаётся делать?

Это другое дело. Зависимости на предоставляемое API должны быть, но
это не должны быть зависимости на модули или image. 
Это может решаться именно таким образом - модуль или ядро будут
провайдить это. Нужно только более жестко оговорить формат и внести в полиси.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] Re: [devel] Q: update kernel-policy

[Ed V. Bartosh]

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

 AF>   On Thu, Jan 22, 2004 at 06:24:49AM +0200, Denis Ovsienko wrote:
 >>   > 1. Никакие пакеты, кроме пакетов вида kernel-modules-XXX и >
 >>  kernel-сomplete-XXX, не могут иметь зависимости на пакеты вида >
 >>  kernel-image-XXX и kernel-modules-XXX.  Почему же? В модулях
 >>  может быть какое-то API, без которого userspace пакет будет
 >>  бесполезным. Или в ядре. Я уже который раз прошу промаркировать
 >>  соответствующие ядра как cryptoapi-kernel, но меня игнорируют,
 >>  поэтому что остаётся делать?
  
 AF>  Пока не понятно, как привязывать userspace к kernelspace, ибо
 AF>  пакетов с ядрами может стоять _огромное количество_, а реальное
 AF>  ядро - совсем не совпадать с тем, что установлено.

Есть такое дело. Но привязывать все равно нужно. Если будет
установлено хотя бы одно ядро или модуль, который провайдит нужное
API, то это уже в принципе обеспечивает работу юзерспейса. 
Да, есть еще дополнительные условия, которые нужно обеспечить, но это
все равно гораздо лучше, чем не иметь таких зависимостей вовсе и как
следствие не иметь даже принципиальной возможности работы
поставленного пакета.

-- 
Best regards,
Ed V. Bartosh

Re: [devel] Q: update kernel-policy

[Sergey Vlasov]

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

On Thu, Jan 22, 2004 at 11:41:53AM +0200, Ed V. Bartosh wrote:
> 
> >>>>> "DO" == Denis Ovsienko writes:
> 
>  >>   1. Никакие пакеты, кроме пакетов вида kernel-modules-XXX и
>  >>  kernel-сomplete-XXX, не могут иметь зависимости на пакеты вида
>  >>  kernel-image-XXX и kernel-modules-XXX.
>  DO>  Почему же? В модулях может быть какое-то API, без которого
>  DO>  userspace пакет будет бесполезным. Или в ядре. Я уже который раз
>  DO>  прошу промаркировать соответствующие ядра как cryptoapi-kernel,
>  DO>  но меня игнорируют, поэтому что остаётся делать?
> 
> Это другое дело. Зависимости на предоставляемое API должны быть, но
> это не должны быть зависимости на модули или image. 
> Это может решаться именно таким образом - модуль или ядро будут
> провайдить это. Нужно только более жестко оговорить формат и внести в полиси.

В том-то и дело, что такие зависимости не решают проблемы - может
быть установлено несколько ядер, только часть из которых
предоставляет API.  Более того, какие-то комбинации могут вообще не
существовать, хотя по отдельности (в разных ядрах) они есть.

А вот проблемы от этих зависимостей реально существуют.  Конечно,
можно считать их ошибками в apt, но от этого не легче.

В документации записано, что пакеты с ядрами не обновляются
автоматически при выполнении apt-get dist-upgrade.  Однако при
наличии хотя бы косвенной зависимости на ядро (через provides в
самом пакете ядра, или даже в пакете с модулями) по этим
зависимостям вполне может вытянуться новое ядро.  Что ещё хуже,
поскольку зависимость будет предоставляться несколькими пакетами
(для разных вариантов ядра), apt будет выбирать один из этих пакетов
самостоятельно - как правило, результат этого выбора никуда не
годится.

Т.е. до внесения каких-то изменений в apt никаких cryptoapi-kernel и
т.п. в Сизифе быть не должно.

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

Re: [d-kernel] Re: [devel] Q: update kernel-policy

[Ed V. Bartosh]

 >> 
 >> Это другое дело. Зависимости на предоставляемое API должны быть, но
 >> это не должны быть зависимости на модули или image. 
 >> Это может решаться именно таким образом - модуль или ядро будут
 >> провайдить это. Нужно только более жестко оговорить формат и внести в полиси.

 SV> В том-то и дело, что такие зависимости не решают проблемы - может
 SV> быть установлено несколько ядер, только часть из которых
 SV> предоставляет API.  Более того, какие-то комбинации могут вообще не
 SV> существовать, хотя по отдельности (в разных ядрах) они есть.
Они не решают проблему на 100%, но обеспечивают работоспособность
пакета в принципе. Без них и этого не будет, что тоже неправильно.
Насчет комбинаций - в большинстве случаев все-таки будет нужно одно
API, а не несколько. Хотя, в принципе да, такая возможность есть.

 SV> А вот проблемы от этих зависимостей реально существуют.  Конечно,
 SV> можно считать их ошибками в apt, но от этого не легче.

 SV> В документации записано, что пакеты с ядрами не обновляются
 SV> автоматически при выполнении apt-get dist-upgrade.  Однако при
 SV> наличии хотя бы косвенной зависимости на ядро (через provides в
 SV> самом пакете ядра, или даже в пакете с модулями) по этим
 SV> зависимостям вполне может вытянуться новое ядро.  Что ещё хуже,
 SV> поскольку зависимость будет предоставляться несколькими пакетами
 SV> (для разных вариантов ядра), apt будет выбирать один из этих пакетов
 SV> самостоятельно - как правило, результат этого выбора никуда не
 SV> годится.
Эначит нужно фиксить apt. Работать без зависимостей - это не наш
метод все-таки, не находишь ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] Re: [devel] Q: update kernel-policy

[Anton Farygin]

On Thu, Jan 22, 2004 at 12:20:11PM +0200, Ed V. Bartosh wrote:
> 
>  >> 
>  >> Это другое дело. Зависимости на предоставляемое API должны быть, но
>  >> это не должны быть зависимости на модули или image. 
>  >> Это может решаться именно таким образом - модуль или ядро будут
>  >> провайдить это. Нужно только более жестко оговорить формат и внести в полиси.
> 
>  SV> В том-то и дело, что такие зависимости не решают проблемы - может
>  SV> быть установлено несколько ядер, только часть из которых
>  SV> предоставляет API.  Более того, какие-то комбинации могут вообще не
>  SV> существовать, хотя по отдельности (в разных ядрах) они есть.
> Они не решают проблему на 100%, но обеспечивают работоспособность
> пакета в принципе. Без них и этого не будет, что тоже неправильно.
> Насчет комбинаций - в большинстве случаев все-таки будет нужно одно
> API, а не несколько. Хотя, в принципе да, такая возможность есть.
> 
>  SV> А вот проблемы от этих зависимостей реально существуют.  Конечно,
>  SV> можно считать их ошибками в apt, но от этого не легче.
> 
>  SV> В документации записано, что пакеты с ядрами не обновляются
>  SV> автоматически при выполнении apt-get dist-upgrade.  Однако при
>  SV> наличии хотя бы косвенной зависимости на ядро (через provides в
>  SV> самом пакете ядра, или даже в пакете с модулями) по этим
>  SV> зависимостям вполне может вытянуться новое ядро.  Что ещё хуже,
>  SV> поскольку зависимость будет предоставляться несколькими пакетами
>  SV> (для разных вариантов ядра), apt будет выбирать один из этих пакетов
>  SV> самостоятельно - как правило, результат этого выбора никуда не
>  SV> годится.
> Эначит нужно фиксить apt. Работать без зависимостей - это не наш
> метод все-таки, не находишь ?

Правильно. Нужно фиксить apt. А еще точнее - посмотреть на Lua и
попробовать на нем реализовать недостающую функциональность для выблора
нужного ядра/пакета. Если, конечно, такое получится.

Rgds,
Rider