[d-kernel] kernel policy

[d-kernel] kernel policy

[nidd]

Kernel Policy for Sisyphus.
===========================

Author: Peter Novodvorsky.


0. Документ и его обновление.
-----------------------------

kernel policy обновляется участниками kernel maintainer committee.
Состав kernel committee:
- Peter 'nidd' Novodvorsky <nidd@altlinux.com>


1. Именование
-------------

1.1 Патчи.
----------

Есть два вида патчей:

kernel-patch-feat-%{upsteram_name}
kernel-patch-fix-%{upstream_name}

В пакетах feat содержатся патчи добавляющие ядру Linux новые
возможности. Это могут быть и драйверы устройств (рекоммендуется
называть такие kernel-patch-feat-dev-<имя_устройста>) и файловых
систем (желательно называть kernel-patch-feat-dev-<имя_файловой
системы>), добавление новых возможностей к сетевой подсистеме
(желательно называть kernel-patch-feat-net-<сокращённое название
улучшения>), а так же добавление новых возможностей к корневой части
(kernel/*, mm/*, arch/*) ядра, (желательно называть
kernel-patch-feat-core-<название улучшения>). 

Все пакеты fixes поддерживаются kernel maintainer commitee. Именуются
по именам подсистем ядра, а так же существует отдельный пакет для
security патчей и build патчей:
kernel-patch-fixes-{net,scsi,ide,fs,vm,core,security,build}.


1.2 Внешние модули.
-------------------

Внешними модулями называются модули, исходные файлы которых
поставляются не в виде патчей и которые можно собрать отдельно от
ядра.

Пакеты с такими собранными модулями должны называться
kernel-<сокращённое название набора модулей>-<версия ядра с которым
собраны модули>-<flavour ядра с которым собраны модули>.

Пакеты с хедерами этих модулей должны назваться kernel-<сокращённое
название набора модулей>-headers-<версия ядра с которым собраны
модули>-<flavour ядра с которым собраны модули>. 

1.3 Пакет с исходными текстами ядра и модулей.
----------------------------------------------

Такие пакеты должен называться: <имя проекта>-source-<версия модулей
или ядра>.

1.4 Пакет с ядром.
------------------

Такой пакет должен называться kernel-image-<версия ядра>-<flavour
ядра>.

Пакет с хедерами ядра должен называться kernel-headers-<версия ядра>-<flavour
ядра>.

2. Versioning пакетов.
----------------------

Пакетам с feat патчами желательно присваивать версии, полученные из
upstream. Если upstream не делает versioning, допустимо называть их по
дате последнего изменения upstream в формате ddmmyy.

Пакетам с fix патчами обязательно присваивать версии по дате
запаковывания в формате ddmmyy.

Пакеатам с внешними модулями и ядром, а так же с их исходными текстами
желательно присваивать версии, полученные из upstream. Если upstream
не делает versioning, допустимо называть их по дате последнего
изменения upstream в формате ddmmyy. 

3. Содержимое пакетов.
----------------------

3.1 Патчи.
----------

/usr/src/patches/<имя_патча>/*            патчи
         patches/apply/<имя_патча>        программа, которая
                                          прикладывает патчи

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

Программа прикладывающая патч, будучи вызванная из каталога с исходными
текстами ядра, обязана приложить к ним нужные патчи или возвратить 1 в
случае ошибки прикладывания. Программа может пользоваться следующими
переменными окружения заданными при запуске в среде:
- APPLIED_PATCHES, переменная содержит список названий уже приложенных
патчей через запятую.
- KVER, версия ядра, к которой нужно приложить патч.

3.2 Пакет с исходными текстами.
--------------------------------

/usr/src/<имя_пакета>-source-<версия>.tar.gz
....

3.3 Пакет с внешними модулями.
-------------------------------

/lib/modules/<версия ядра>-<flavour>/*
/usr/include/linux-<версия ядра>-<flavour>/*
....

3.4 Пакет с ядром.
------------------

image:
/boot/config-<версия ядра>-<flavour>-<release>
/boot/vmlinuz-<версия ядра>-<flavour>-<release>
/boot/System.map-<версия ядра>-<flavour>-<release>
/lib/modules/<версия ядра>-<flavour>-<release>/*

headers:
/usr/include/linux-<версия ядра>-<flavour>/*

....

4. Порядок принятия новых пакетов в Sisyphus.
---------------------------------------------

Дабы упорядочить вхождение новых пакетов в Sisyphus, сначала
разработчик обязан написать письмо в devel-kernel@altlinux.ru с темой
ITP: <имя_пакета> (Intent to package) и с descriptionом пакета в теле,
чтобы пояснить, что новое он хочет добавить. Далее проходит обсуждение
этого пакета и люди договариваются, целесообразно ли присутствие
пакета в Sisyphus. Kernel maintainer maintainer committee имеет право
наложить вето на вхождение пакета в Sisyphus при согласии всех
участников KMC.





-- 
Peter Novodvorsky                             nidd@myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!
           Kill 'em all, and let God sort 'em out

Re: [d-kernel] kernel policy

[Sviatoslav Sviridov]

On Tue, 15 Apr 2003 18:40:45 +0400
nidd@myxomop.com wrote:

> Пакеатам с внешними модулями и ядром, а так же с их исходными текстами
> желательно присваивать версии, полученные из upstream. Если upstream
> не делает versioning, допустимо называть их по дате последнего
> изменения upstream в формате ddmmyy. 

может лучше в формате yyyymmdd?
-- 
Sviatoslav Sviridoff
// Lintec Project/Minsk // PIN AG/Berlin //
-- 
Man is an animal that makes bargains: no other animal does this--
no dog exchanges bones with another.
		-- Adam Smith

[d-kernel] Re: kernel policy

[Sergey Vlasov]

On Tue, 15 Apr 2003 17:56:00 +0400
Sviatoslav Sviridov <svd@lintec.minsk.by> wrote:

> On Tue, 15 Apr 2003 18:40:45 +0400
> nidd@myxomop.com wrote:
> 
> > Пакеатам с внешними модулями и ядром, а так же с их исходными текстами
> > желательно присваивать версии, полученные из upstream. Если upstream
> > не делает versioning, допустимо называть их по дате последнего
> > изменения upstream в формате ddmmyy. 
> 
> может лучше в формате yyyymmdd?

Да уж - а то ерунда получится.

Re: [d-kernel] kernel policy

[Ed V. Bartosh]

Hello,

 n> Есть два вида патчей:

 n> kernel-patch-feat-%{upsteram_name}
 n> kernel-patch-fix-%{upstream_name}
Предлагаю убрать patch- из названия:
kernel-feat-%{upsteram_name}
kernel-fix-%{upstream_name}

По-моему достаточно информативно и короче.

 n> Все пакеты fixes поддерживаются kernel maintainer commitee. Именуются
 n> по именам подсистем ядра, а так же существует отдельный пакет для
 n> security патчей и build патчей:
 n> kernel-patch-fixes-{net,scsi,ide,fs,vm,core,security,build}.
Предлагаю сделать пакет kernel-build-tools с макросами/скриптами/etc
применяющимися при сборке ядер.
У меня уже есть, что туда положить :)

 n> 1.2 Внешние модули.
 n> -------------------

 n> Внешними модулями называются модули, исходные файлы которых
 n> поставляются не в виде патчей и которые можно собрать отдельно от
 n> ядра.

 n> Пакеты с такими собранными модулями должны называться
 n> kernel-<сокращённое название набора модулей>-<версия ядра с которым
 n> собраны модули>-<flavour ядра с которым собраны модули>.
Предлагаю kernel-module-..., соответственно kernel-module-название-headers и
kernel-module-название-source

И еще - а зачем вообще эти модули нужны ? Предлагаю избавиться от них
или хотя бы минимизировать их количество. 
Или описать здесь принципы выноса бинарных модулей в отдельный пакет. 
Я как-то до сих пор их не уяснил :(

 n> 1.4 Пакет с ядром.
 n> ------------------

 n> Такой пакет должен называться kernel-image-<версия ядра>-<flavour
 n> ядра>.
Что есть flavor в данном случае ?
Может flavor-subflavor (std-up) ?

 n> 2. Versioning пакетов.
 n> ----------------------

 n> Пакетам с feat патчами желательно присваивать версии, полученные из
 n> upstream. Если upstream не делает versioning, допустимо называть их по
 n> дате последнего изменения upstream в формате ddmmyy.

 n> Пакетам с fix патчами обязательно присваивать версии по дате
 n> запаковывания в формате ddmmyy.
Здесь можно привести формат имени таких пакетов.

 n> 3.1 Патчи.
 n> ----------

 n> /usr/src/patches/<имя_патча>/*            патчи
/usr/src/kernel/patches/<имя_патча>/*

 n> patches/apply/<имя_патча>        программа, которая
/usr/src/kernel/patches/apply/<имя_патча>

Вместе с патчами могут ставиться и тарболы, предлагаю их
ставить в /usr/src/kernel/patches/src/<имя_патча>/
В отдельный пакет с сорцами уж точно нет смысла это выносить.

 n> прикладывает патчи
Считаю, что apply-программы вещь опциональная, а стандартное
приложение патчей должно быть выполнено в виде макроса.
Такой макрос уже есть.

 n> Патчи внутри каталога могут находиться в любом расположении, это не
 n> определяется данным документом.
Предлагаю определить, иначе будет затруднено вынесение общего
функционала в макрос.

 n> Программа прикладывающая патч, будучи вызванная из каталога с исходными
 n> текстами ядра, обязана приложить к ним нужные патчи или возвратить 1 в
 n> случае ошибки прикладывания. Программа может пользоваться следующими
 n> переменными окружения заданными при запуске в среде:
 n> - APPLIED_PATCHES, переменная содержит список названий уже приложенных
 n> патчей через запятую.
 n> - KVER, версия ядра, к которой нужно приложить патч.
Не уверен, что это нужно. 

 n> 3.2 Пакет с исходными текстами.
 n> --------------------------------

 n> /usr/src/<имя_пакета>-source-<версия>.tar.gz
 n> ....
Это для самого ядра и для модулей ?

Вот мои пожелания, которые я не успел отправить, вернее их часть.
Примите во внимание, плз:

Принципы сборки/установки:
1. Тарболы с сорцами ядер устанавливаются в /usr/src
2. Пачти называются NN-название.patch, где NN определяет порядок приложения.
   устанавливаются в /usr/src/kernel/patches/название_пакета/
3. Условное приложение патчей достигается путем установки
   патча в каталог /usr/src/kernel/patches/название_пакета/название_required_пакета
   Такой патч будет приложен только при условии того, что приложены
   патчи из пакета 'название_required_пакета'
4. При условии успешного приложения пакета патчей в каталоге ./patches
   соответствующего дерева kernel sources должен создаваться файл
   APPLIED_имя_пакета
5. Тарболы с сорцами, используемыми пакетом с патчами устанавливаются в 
   /usr/src/kernel/patches/src/название_пакета/
6. Стандартные действия по установке патчей производятся с помощью
   макроса(ов) из пакета kernel-build-tools 
7. Нестандартная действия по установке/приложению патчей производятся
   в скриптах имя_пакета-apply и устанавливаются в /usr/src/kernel/patches/apply
8. Распаковка sources, приложение патчей производится
   при сборке kernel-image
9. В репозитарии не должно быть бинарных пакетов с модулями, все
   модули должны находиться в соответствующем kernel-image

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy

[Peter Novodvorsky]

ed@sam-solutions.net (Ed V. Bartosh) writes:

>  n> Есть два вида патчей:
>
>  n> kernel-patch-feat-%{upsteram_name}
>  n> kernel-patch-fix-%{upstream_name}
> Предлагаю убрать patch- из названия:
> kernel-feat-%{upsteram_name}
> kernel-fix-%{upstream_name}
>
> По-моему достаточно информативно и короче.

это не информативно. это не говорит, что это -- патч. Может ещё
-source- убрать?

> Предлагаю сделать пакет kernel-build-tools с макросами/скриптами/etc
> применяющимися при сборке ядер.
> У меня уже есть, что туда положить :)

окей.

>
>  n> 1.2 Внешние модули.
>  n> -------------------
>
>  n> Внешними модулями называются модули, исходные файлы которых
>  n> поставляются не в виде патчей и которые можно собрать отдельно от
>  n> ядра.
>
>  n> Пакеты с такими собранными модулями должны называться
>  n> kernel-<сокращённое название набора модулей>-<версия ядра с которым
>  n> собраны модули>-<flavour ядра с которым собраны модули>.
> Предлагаю kernel-module-..., соответственно kernel-module-название-headers и
> kernel-module-название-source
>
> И еще - а зачем вообще эти модули нужны ? Предлагаю избавиться от них
> или хотя бы минимизировать их количество. 
> Или описать здесь принципы выноса бинарных модулей в отдельный пакет. 
> Я как-то до сих пор их не уяснил :(

Это те модули которые уже вынесены. См. kernel-alsa-2.4.21pre-std-up
src rpm. Нет, не судьба называть их kernel-module.

>
>  n> 1.4 Пакет с ядром.
>  n> ------------------
>
>  n> Такой пакет должен называться kernel-image-<версия ядра>-<flavour
>  n> ядра>.
> Что есть flavor в данном случае ?
> Может flavor-subflavor (std-up) ?

Да-да.


>
>  n> 2. Versioning пакетов.
>  n> ----------------------
>
>  n> Пакетам с feat патчами желательно присваивать версии, полученные из
>  n> upstream. Если upstream не делает versioning, допустимо называть их по
>  n> дате последнего изменения upstream в формате ddmmyy.
>
>  n> Пакетам с fix патчами обязательно присваивать версии по дате
>  n> запаковывания в формате ddmmyy.
> Здесь можно привести формат имени таких пакетов.


secfixes. будут выглядеть именно так.

>
>  n> 3.1 Патчи.
>  n> ----------
>
>  n> /usr/src/patches/<имя_патча>/*            патчи
> /usr/src/kernel/patches/<имя_патча>/*
>
>  n> patches/apply/<имя_патча>        программа, которая
> /usr/src/kernel/patches/apply/<имя_патча>
>


окей-окей.

> Вместе с патчами могут ставиться и тарболы, предлагаю их
> ставить в /usr/src/kernel/patches/src/<имя_патча>/
> В отдельный пакет с сорцами уж точно нет смысла это выносить.

Да, но то как патч распологает свои файлы, -- не дело полиси, в этом
разбирается скрипт apply.

>
>  n> прикладывает патчи
> Считаю, что apply-программы вещь опциональная, а стандартное
> приложение патчей должно быть выполнено в виде макроса.
> Такой макрос уже есть.

Нет, не опциальная. Если нужно, -- можно сделать
/usr/lib/kernel-build-tools/apply, а все apply программы будут просто
соурсить этот файл.

>
>  n> Патчи внутри каталога могут находиться в любом расположении, это не
>  n> определяется данным документом.
> Предлагаю определить, иначе будет затруднено вынесение общего
> функционала в макрос.


В среднем, будет один и тот же алгоритм. Но надо оставить за
патче-пакето-твроителями полную свободу в том, как и что патчить. 

>
>  n> Программа прикладывающая патч, будучи вызванная из каталога с исходными
>  n> текстами ядра, обязана приложить к ним нужные патчи или возвратить 1 в
>  n> случае ошибки прикладывания. Программа может пользоваться следующими
>  n> переменными окружения заданными при запуске в среде:
>  n> - APPLIED_PATCHES, переменная содержит список названий уже приложенных
>  n> патчей через запятую.
>  n> - KVER, версия ядра, к которой нужно приложить патч.
> Не уверен, что это нужно. 

Нужно. Почему не нужно?


>
>  n> 3.2 Пакет с исходными текстами.
>  n> --------------------------------
>
>  n> /usr/src/<имя_пакета>-source-<версия>.tar.gz
>  n> ....
> Это для самого ядра и для модулей ?
>
> Вот мои пожелания, которые я не успел отправить, вернее их часть.
> Примите во внимание, плз:
>
> Принципы сборки/установки:
> 1. Тарболы с сорцами ядер устанавливаются в /usr/src
> 2. Пачти называются NN-название.patch, где NN определяет порядок приложения.
>    устанавливаются в /usr/src/kernel/patches/название_пакета/

Это не регулируется policy.

> 3. Условное приложение патчей достигается путем установки
>    патча в каталог /usr/src/kernel/patches/название_пакета/название_required_пакета
>    Такой патч будет приложен только при условии того, что приложены
>    патчи из пакета 'название_required_пакета'

Это рекоммендованный но не обязательный способ.

> 4. При условии успешного приложения пакета патчей в каталоге ./patches
>    соответствующего дерева kernel sources должен создаваться файл
>    APPLIED_имя_пакета

Это рекоммендация.

> 5. Тарболы с сорцами, используемыми пакетом с патчами устанавливаются в 
>    /usr/src/kernel/patches/src/название_пакета/

это рекоммендация.

> 6. Стандартные действия по установке патчей производятся с помощью
>    макроса(ов) из пакета kernel-build-tools 

шелл-библиотеки из пакета kernel-build-tools, которая соурсится каждым
из apply-скриптов.

> 7. Нестандартная действия по установке/приложению патчей производятся
>    в скриптах имя_пакета-apply и устанавливаются в
> /usr/src/kernel/patches/apply

Не понимаю. Зачем делать условный оператор?

> 8. Распаковка sources, приложение патчей производится
>    при сборке kernel-image

Да.

> 9. В репозитарии не должно быть бинарных пакетов с модулями, все
>    модули должны находиться в соответствующем kernel-image

Нет. Все модули, которые могут собираться отдельно от ядра собираются
отдельно от ядра. как то: alsa, i2c, lm_sensors, и так далее,
см. сизиф.

Спасибо за комментарии,
Пётр.

-- 
Peter Novodvorsky                             nidd@myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!

Re: [d-kernel] kernel policy

[aen]

Peter Novodvorsky пишет:

>ed@sam-solutions.net (Ed V. Bartosh) writes:
>
>  
>
>> n> 1.2 Внешние модули.
>> n> -------------------
>>
>> n> Внешними модулями называются модули, исходные файлы которых
>> n> поставляются не в виде патчей и которые можно собрать отдельно от
>> n> ядра.
>>
>> n> Пакеты с такими собранными модулями должны называться
>> n> kernel-<сокращённое название набора модулей>-<версия ядра с которым
>> n> собраны модули>-<flavour ядра с которым собраны модули>.
>>Предлагаю kernel-module-..., соответственно kernel-module-название-headers и
>>kernel-module-название-source
>>
>>И еще - а зачем вообще эти модули нужны ? Предлагаю избавиться от них
>>или хотя бы минимизировать их количество. 
>>Или описать здесь принципы выноса бинарных модулей в отдельный пакет. 
>>Я как-то до сих пор их не уяснил :(
>>    
>>
>
>Это те модули которые уже вынесены. См. kernel-alsa-2.4.21pre-std-up
>src rpm. Нет, не судьба называть их kernel-module.
>
Как я представляю, смысл в том, что такие модули собираются отдельно от 
ядра и, соотвественно, для установки новой версии пакета, собранной с 
тем же ядром, заведомо не надо обновлять ядро. Это особенно полезно, 
например, в случае фиксов alsa или новых версий nvidia.

>
>  
>
>> 
>>
< skip >

>  
>
>>9. В репозитарии не должно быть бинарных пакетов с модулями, все
>>   модули должны находиться в соответствующем kernel-image
>>    
>>
>
>Нет. Все модули, которые могут собираться отдельно от ядра собираются
>отдельно от ядра. как то: alsa, i2c, lm_sensors, и так далее,
>см. сизиф.
>
Компромиссом может быть пакет, имеющий зависисмости на image и все 
модули, о чем я писал ранее.

Rgrds, Алексей

Re: [d-kernel] kernel policy

[Ed V. Bartosh]

Hello,

 >>> И еще - а зачем вообще эти модули нужны ? Предлагаю избавиться от них
 >>> или хотя бы минимизировать их количество. Или описать здесь
 >>> принципы выноса бинарных модулей в отдельный пакет. Я как-то до сих
 >>> пор их не уяснил :(

 >> 
 >> Это те модули которые уже вынесены. См. kernel-alsa-2.4.21pre-std-up
 >> src rpm. Нет, не судьба называть их kernel-module.
 >> 
 a> Как я представляю, смысл в том, что такие модули собираются отдельно
 a> от ядра и, соотвественно, для установки новой версии пакета, собранной
 a> с тем же ядром, заведомо не надо обновлять ядро. Это особенно полезно,
 a> например, в случае фиксов alsa или новых версий nvidia.

То есть в случае других фиксов kernel-image будет пересобираться, а в
случае фиксов alsa нет ? То есть вынесение модуля в отдельный пакет
происходит исходя из частоты его обновления, я правильно понял ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy

[aen]

Ed V. Bartosh пишет:

>Hello,
>
> >>> И еще - а зачем вообще эти модули нужны ? Предлагаю избавиться от них
> >>> или хотя бы минимизировать их количество. Или описать здесь
> >>> принципы выноса бинарных модулей в отдельный пакет. Я как-то до сих
> >>> пор их не уяснил :(
>
> >> 
> >> Это те модули которые уже вынесены. См. kernel-alsa-2.4.21pre-std-up
> >> src rpm. Нет, не судьба называть их kernel-module.
> >> 
> a> Как я представляю, смысл в том, что такие модули собираются отдельно
> a> от ядра и, соотвественно, для установки новой версии пакета, собранной
> a> с тем же ядром, заведомо не надо обновлять ядро. Это особенно полезно,
> a> например, в случае фиксов alsa или новых версий nvidia.
>
>То есть в случае других фиксов kernel-image будет пересобираться, а в
>случае фиксов alsa нет ? То есть вынесение модуля в отдельный пакет
>происходит исходя из частоты его обновления, я правильно понял ?
>
>  
>
Из асинхронности его обновления с обновлением ядра. Так как в любом 
случае модуль пересобрать и скачать быстрее, то что меняется чаще -- не 
суть важно.

Rgrds, Алексей

Re: [d-kernel] kernel policy

[Ed V. Bartosh]

Hi,

 a> от ядра и, соотвественно, для установки новой версии пакета, собранной
 a> с тем же ядром, заведомо не надо обновлять ядро. Это особенно полезно,
 a> например, в случае фиксов alsa или новых версий nvidia.
 >> 
 >> То есть в случае других фиксов kernel-image будет пересобираться, а в
 >> случае фиксов alsa нет ? То есть вынесение модуля в отдельный пакет
 >> происходит исходя из частоты его обновления, я правильно понял ?
 >> 
 >> 

 a> Из асинхронности его обновления с обновлением ядра. Так
 a> как в любом случае модуль пересобрать и скачать быстрее,
 a> то что меняется чаще -- не суть важно.
Понятно.

Я все-таки хочу дообсуждать тему отдельных пакетов с модулями.
Можно рассмотреть 2 схемы:
1 - стратегия выноса в отдельные пакеты как можно большего количества
    функционала. Плюсы здесь есть неоспоримые - ядро меньше, проще
    апгрэйдить на продекшен системах (без перезагрузки), можно брать и
    ставить только тот функционал, который нужен. 
    Минусы тоже присутствуют, основной - большое количество пакетов, 
    ведь их нужно будет собирать под конкретные ядра.
2 - противоположная стратегия - сборка как можно большего количества
    модулей вместе с ядром, в составе kernel-image. Здесь с минусами и
    плюсами все наоборот.

Истина где-то между этими двумя крайностями, IMHO. 
А вот где, неплохо бы выяснить. Кто что скажет ?

И еще: Возможно было бы пойти по первой схеме, только иметь
некое базовое собранное ядро (без фич, только с фиксами) и пакеты
модулей, собранных относительно этой базы.
А окончательные kernel-image будут просто пакетами, которые будут
составлять некие наборы из базы и модулей.
Возможно в этом случае удалось бы избежать основных
недостатков схемы 1.
Давайте обсудим, считаю, что это вопрос стратегический.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy

[Anton Farygin]

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

Ed V. Bartosh пишет:
> Hi,
> 
>  a> от ядра и, соотвественно, для установки новой версии пакета, собранной
>  a> с тем же ядром, заведомо не надо обновлять ядро. Это особенно полезно,
>  a> например, в случае фиксов alsa или новых версий nvidia.
>  >> 
>  >> То есть в случае других фиксов kernel-image будет пересобираться, а в
>  >> случае фиксов alsa нет ? То есть вынесение модуля в отдельный пакет
>  >> происходит исходя из частоты его обновления, я правильно понял ?
>  >> 
>  >> 
> 
>  a> Из асинхронности его обновления с обновлением ядра. Так
>  a> как в любом случае модуль пересобрать и скачать быстрее,
>  a> то что меняется чаще -- не суть важно.
> Понятно.
> 
> Я все-таки хочу дообсуждать тему отдельных пакетов с модулями.
> Можно рассмотреть 2 схемы:
> 1 - стратегия выноса в отдельные пакеты как можно большего количества
>     функционала. Плюсы здесь есть неоспоримые - ядро меньше, проще
>     апгрэйдить на продекшен системах (без перезагрузки), можно брать и
>     ставить только тот функционал, который нужен. 
>     Минусы тоже присутствуют, основной - большое количество пакетов, 
>     ведь их нужно будет собирать под конкретные ядра.

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

> 2 - противоположная стратегия - сборка как можно большего количества
>     модулей вместе с ядром, в составе kernel-image. Здесь с минусами и
>     плюсами все наоборот.

Я бы предложил среднее: то, что необходимо для программы установки (в 
плане функциональности) нам нужно включать в kernel-image. Все остальное 
(например freeswan) - выносить в отдельные пакеты. По мере появления 
поставляемой из коробки функциональности (а также по мере тестирования 
сторонних модулей) - переносить в базовое ядро необходимые модули.

> 
> Истина где-то между этими двумя крайностями, IMHO. 
> А вот где, неплохо бы выяснить. Кто что скажет ?
> 
> И еще: Возможно было бы пойти по первой схеме, только иметь
> некое базовое собранное ядро (без фич, только с фиксами) и пакеты
> модулей, собранных относительно этой базы.
> А окончательные kernel-image будут просто пакетами, которые будут
> составлять некие наборы из базы и модулей.
> Возможно в этом случае удалось бы избежать основных
> недостатков схемы 1.
> Давайте обсудим, считаю, что это вопрос стратегический.

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

Rgds,
Rider



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

Re: [d-kernel] kernel policy

[Ed V. Bartosh]

Hello,

 >> Можно рассмотреть 2 схемы:
 >> 1 - стратегия выноса в отдельные пакеты как можно большего количества
 >> функционала. Плюсы здесь есть неоспоримые - ядро меньше, проще
 >> апгрэйдить на продекшен системах (без перезагрузки), можно брать и
 >> ставить только тот функционал, который нужен.
 >> Минусы тоже присутствуют, основной - большое количество
 >> пакетов,     ведь их нужно будет собирать под
 >> конкретные ядра.

 AF> Еще один минус - придется увязывать названия пакетов с
 AF> оборудованием и функционалом. Ибо для правильной
 AF> установки этого в программе установки придется немного
 AF> поработать. Сейчас же устанавливается ядро, в котором
 AF> просто все есть.
Инсталлятор - это, конечно, важный элемент дистрибутива, но я бы не стал
привязываться к нему в данном вопросе. Гораздо важнее удобство
эксплуатации ядерных пакетов. Инсталлятор - это ведь только начало, да
и поправить его в нужную сторону проще, чем потом иметь проблемы с остальным.

 >> 2 - противоположная стратегия - сборка как можно большего количества
 >> модулей вместе с ядром, в составе kernel-image. Здесь с минусами и
 >> плюсами все наоборот.

 AF> Я бы предложил среднее: то, что необходимо для программы
 AF> установки (в плане функциональности) нам нужно включать в
 AF> kernel-image. Все остальное (например freeswan) -
 AF> выносить в отдельные пакеты. По мере появления
 AF> поставляемой из коробки функциональности (а также по мере
 AF> тестирования сторонних модулей) - переносить в базовое
 AF> ядро необходимые модули.
Я бы не рассматривал здесь требования инсталлятора, неправильно это.
Никто не мешает загрузить нужные модули и в процессе инсталляции.

 >> И еще: Возможно было бы пойти по первой схеме, только
 >> иметь

 >> некое базовое собранное ядро (без фич, только с фиксами) и пакеты
 >> модулей, собранных относительно этой базы.
 >> А окончательные kernel-image будут просто пакетами, которые будут
 >> составлять некие наборы из базы и модулей.
 >> Возможно в этом случае удалось бы избежать основных
 >> недостатков схемы 1.
 >> Давайте обсудим, считаю, что это вопрос стратегический.

 AF> мне если честно не очень нравится идея сильного дробления
 AF> ядра на модули. тяжело собирать, отслеживать зависимости,
 AF> устанавливать и многое другое.  Тогда уж лучше
 AF> реализовать мою идею с поставкой не упакованного в пакет
 AF> ядра и спец. скриптом, устанавливающим только необходимые
 AF> для данной машины модули.
Поясни, плз, поподробнее, я недопонял. Как это "не упакованного
в пакет" ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy

[Anton Farygin]

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

Ed V. Bartosh пишет:
> Hello,
> 
>  >> Можно рассмотреть 2 схемы:
>  >> 1 - стратегия выноса в отдельные пакеты как можно большего количества
>  >> функционала. Плюсы здесь есть неоспоримые - ядро меньше, проще
>  >> апгрэйдить на продекшен системах (без перезагрузки), можно брать и
>  >> ставить только тот функционал, который нужен.
>  >> Минусы тоже присутствуют, основной - большое количество
>  >> пакетов,     ведь их нужно будет собирать под
>  >> конкретные ядра.
> 
>  AF> Еще один минус - придется увязывать названия пакетов с
>  AF> оборудованием и функционалом. Ибо для правильной
>  AF> установки этого в программе установки придется немного
>  AF> поработать. Сейчас же устанавливается ядро, в котором
>  AF> просто все есть.
> Инсталлятор - это, конечно, важный элемент дистрибутива, но я бы не стал
> привязываться к нему в данном вопросе. Гораздо важнее удобство
> эксплуатации ядерных пакетов. Инсталлятор - это ведь только начало, да
> и поправить его в нужную сторону проще, чем потом иметь проблемы с остальным.

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

Пример: у меня есть некая железка, неизвестного производителя. lspci 
сказал, что для нее неплохо было бы использовать драйвер noname.o, 
которого в стандартном ядре не оказалось. Вопрос - где искать этот драйвер?

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

> 
>  >> 2 - противоположная стратегия - сборка как можно большего количества
>  >> модулей вместе с ядром, в составе kernel-image. Здесь с минусами и
>  >> плюсами все наоборот.
> 
>  AF> Я бы предложил среднее: то, что необходимо для программы
>  AF> установки (в плане функциональности) нам нужно включать в
>  AF> kernel-image. Все остальное (например freeswan) -
>  AF> выносить в отдельные пакеты. По мере появления
>  AF> поставляемой из коробки функциональности (а также по мере
>  AF> тестирования сторонних модулей) - переносить в базовое
>  AF> ядро необходимые модули.
> Я бы не рассматривал здесь требования инсталлятора, неправильно это.
> Никто не мешает загрузить нужные модули и в процессе инсталляции.

Тогда нам соответственно нужна будет таблица аля ldetect-lst, в которой 
будет прописано, в каких пакетах - какие модули.

Необходимо будет поправить kudzu и инсталятор от MDK на предмет 
использования этой таблицы при определении устройств и установке пакетов.

kudzu придется править достаточно сильно.

> 
>  >> И еще: Возможно было бы пойти по первой схеме, только
>  >> иметь
> 
>  >> некое базовое собранное ядро (без фич, только с фиксами) и пакеты
>  >> модулей, собранных относительно этой базы.
>  >> А окончательные kernel-image будут просто пакетами, которые будут
>  >> составлять некие наборы из базы и модулей.
>  >> Возможно в этом случае удалось бы избежать основных
>  >> недостатков схемы 1.
>  >> Давайте обсудим, считаю, что это вопрос стратегический.
> 
>  AF> мне если честно не очень нравится идея сильного дробления
>  AF> ядра на модули. тяжело собирать, отслеживать зависимости,
>  AF> устанавливать и многое другое.  Тогда уж лучше
>  AF> реализовать мою идею с поставкой не упакованного в пакет
>  AF> ядра и спец. скриптом, устанавливающим только необходимые
>  AF> для данной машины модули.
> Поясни, плз, поподробнее, я недопонял. Как это "не упакованного
> в пакет" ?

Все модули идут не в пакете, а просто в архиве. Устанавливается не 
пакет, а конкретный модуль, необходимый для поддержки устройства или 
функциональности. Делается это достаточно простым скриптом.

Rgds,
Rider


P.S.
Просьба не забывать о готовящейся версии Junior 2.3

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

Re: [d-kernel] kernel policy

[Ed V. Bartosh]

Hello, Anton

 AF> оборудованием и функционалом. Ибо для правильной
 AF> установки этого в программе установки придется немного
 AF> поработать. Сейчас же устанавливается ядро, в котором
 AF> просто все есть.
 >> Инсталлятор - это, конечно, важный элемент дистрибутива, но я бы не стал
 >> привязываться к нему в данном вопросе. Гораздо важнее удобство
 >> эксплуатации ядерных пакетов. Инсталлятор - это ведь только начало, да
 >> и поправить его в нужную сторону проще, чем потом иметь проблемы с остальным.

 AF> Удобство эксплуатации - безусловно, важный момент. А о
 AF> каком удобстве _эксплуатации_ может идти речь, если
 AF> вместо одного пакета появляется десяток-другой ?
Это для сборщиков-комплектаторов ядер этих пакетов десятки, это и
позволяет гибко комплектовать окончательные kernel-image с набором
нужных фич. А для юзера собственно ничего не меняется - он берет
понравившийся kernel-image и ставит себе. Не хочет задумываться -
берет std. Зато потом начинаются бонусы - обновляется какая-нибудь
alsa и это не повод для вытягивания нового ядра, апгрэйдится только
один пакет, модуль перегрузил и все. Алса - это так, игрушки. А когда
это, скажем, сетевые драйверы на продакшен сервере или еще что-нибудь
такого же плана ?

 AF> Пример: у меня есть некая железка, неизвестного
 AF> производителя. lspci сказал, что для нее неплохо было бы
 AF> использовать драйвер noname.o, которого в стандартном
 AF> ядре не оказалось. Вопрос - где искать этот драйвер?
В ядре, используемом для инсталяции и в std должно быть все железо. 
В терминах пакетов - все пакеты kernel-feat-drivers-...
Да и в остальных ядрах, кроме узкоспециализированных, заточеных под
конкретное железо, тоже. Тогда таких проблем не будет.

 AF> Т.е. - я к тому, что меняя инфраструктуру ядра нужно
 AF> позаботиться от том, что бы пользователи не получили
 AF> больших и неожиданных проблем, связанных с отсутствием
 AF> удобного средства установки необходимых ядерных пакетов.
Согласен, для этого мы это все здесь и обсуждаем.

 AF> Я бы предложил среднее: то, что необходимо для
 >> программы
 AF> установки (в плане функциональности) нам нужно включать в
 AF> kernel-image. Все остальное (например freeswan) -
 AF> выносить в отдельные пакеты. По мере появления
 AF> поставляемой из коробки функциональности (а также по мере
 AF> тестирования сторонних модулей) - переносить в базовое
 AF> ядро необходимые модули.
 >> Я бы не рассматривал здесь требования инсталлятора, неправильно это.
 >> Никто не мешает загрузить нужные модули и в процессе инсталляции.

 AF> Тогда нам соответственно нужна будет таблица аля
 AF> ldetect-lst, в которой будет прописано, в каких пакетах -
 AF> какие модули.
Не обязательно, если включить в ядро все железо. В виде зависимостей
на пакеты с драйверами, а не собирать с ядром. По возможности, конечно.

 AF> Необходимо будет поправить kudzu и инсталятор от MDK на
 AF> предмет использования этой таблицы при определении
 AF> устройств и установке пакетов.

 AF> kudzu придется править достаточно сильно.
А если гарантированно все пакеты с железом будут проставлены ?

 AF> ядра на модули. тяжело собирать, отслеживать зависимости,
 AF> устанавливать и многое другое.  Тогда уж лучше
 AF> реализовать мою идею с поставкой не упакованного в пакет
 AF> ядра и спец. скриптом, устанавливающим только необходимые
 AF> для данной машины модули.
 >> Поясни, плз, поподробнее, я недопонял. Как это "не упакованного
 >> в пакет" ?

 AF> Все модули идут не в пакете, а просто в
 AF> архиве. Устанавливается не пакет, а конкретный модуль,
 AF> необходимый для поддержки устройства или
 AF> функциональности. Делается это достаточно простым
 AF> скриптом.
Все модули ? И каждый раз при обновлении какого-либо драйвера этот
архив пересобирать ? И ядро пересобирать ? 
И вытаскивать/устанавливать ?
И чем это лучше пересборки и установки одной
rpm-ки с нужными модулями ? Причем пересобирать ее будет ее
мэйнтейнер, а собиратель kernel-image только пропишет этот пакет
в 'Requires:'. Или я таки чего-то недопонимаю ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy

[Anton Farygin]

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

Ed V. Bartosh пишет:
> Hello, Anton
>  AF> Удобство эксплуатации - безусловно, важный момент. А о
>  AF> каком удобстве _эксплуатации_ может идти речь, если
>  AF> вместо одного пакета появляется десяток-другой ?
> Это для сборщиков-комплектаторов ядер этих пакетов десятки, это и
> позволяет гибко комплектовать окончательные kernel-image с набором
> нужных фич. А для юзера собственно ничего не меняется - он берет
> понравившийся kernel-image и ставит себе. Не хочет задумываться -
> берет std. Зато потом начинаются бонусы - обновляется какая-нибудь
> alsa и это не повод для вытягивания нового ядра, апгрэйдится только
> один пакет, модуль перегрузил и все. Алса - это так, игрушки. А когда
> это, скажем, сетевые драйверы на продакшен сервере или еще что-нибудь
> такого же плана ?

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

Пример - выход ядра 2.4.21-финального. Как я понимаю сейчас процесс 
сборки ядра будет выглядеть примерно так:

1) Nidd собирает kernel-source и выкладывает
2) Мантейнеры соответствующих патчей начинают портировать свои патчи на 
новое ядро. До тех пор, пока все не запортируются - нет возможности 
собрать std-sub ядро
3) После портирования патчей мантейнеры ядер начинают медленно и упорно 
собирать собственно сами ядра (не забыть, что еще нужно всем владельцам 
пакетов kernel-feat, входящим в kernel-image запортироваться на новое 
ядро (если есть необходимость))

Лично мне не очень нравится пункт 2, ибо тогда задержка с портированием 
хоть одного мантейнера патча или функционала будет держать всех 
остальных. Есть идеи, как это обойти ? Может быть прописать в policy, 
что в случае задержек мантейнер ядра имеет право пересобрать пакет с 
функционалом?


> 
>  AF> Пример: у меня есть некая железка, неизвестного
>  AF> производителя. lspci сказал, что для нее неплохо было бы
>  AF> использовать драйвер noname.o, которого в стандартном
>  AF> ядре не оказалось. Вопрос - где искать этот драйвер?
> В ядре, используемом для инсталяции и в std должно быть все железо. 
> В терминах пакетов - все пакеты kernel-feat-drivers-...
> Да и в остальных ядрах, кроме узкоспециализированных, заточеных под
> конкретное железо, тоже. Тогда таких проблем не будет.
> 

да, конечно.

>  AF> Тогда нам соответственно нужна будет таблица аля
>  AF> ldetect-lst, в которой будет прописано, в каких пакетах -
>  AF> какие модули.
> Не обязательно, если включить в ядро все железо. В виде зависимостей
> на пакеты с драйверами, а не собирать с ядром. По возможности, конечно.

Да. Понял. Но все-таки неплохо было бы иметь такую возможность - ставить 
только те пакеты с драйверами, которые необходимы. Собственно в 
инсталяторе есть сейчас такая штука, но она реализована в виде хаков 
(прямо прописаны какие пакеты устанавливать если есть потребность в 
определенном драйвере). Но от таблицы я бы не отказался - будет хороший 
помошник для авторов kernel-image.

> 
>  AF> Необходимо будет поправить kudzu и инсталятор от MDK на
>  AF> предмет использования этой таблицы при определении
>  AF> устройств и установке пакетов.
> 
>  AF> kudzu придется править достаточно сильно.
> А если гарантированно все пакеты с железом будут проставлены ?

Тогда проблем не возникнет. Вопрос тогда в том, какой виртуальный пакет 
будет ставить все пакеты с железом и как сделать так, что бы все пакеты 
с железом пападали в список зависимостей у виртуального пакета. 
Желательно - автоматически ;-)

> Все модули ? И каждый раз при обновлении какого-либо драйвера этот
> архив пересобирать ? И ядро пересобирать ? 

Нет, ядро не пересобирать.Пересобирается модуль и генерится некий файл с 
описанием какие модули есть, каких ??? версий ???. Т.е. - фактически 
репозитарий драйверов.

> И вытаскивать/устанавливать ?

Через сеть можно забирать только модули.


P.S.
По поводу репозитария драйверов - это мысли вслух. Просьба тем, кто 
считает это бредом - не комментировать. И так ясно, что  этот путь 
сложен и необычен. Это как бы предложение по улучшению текущей структуры.

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

Re: [d-kernel] kernel policy

[Ed V. Bartosh]

Hello, Anton

 >> Это для сборщиков-комплектаторов ядер этих пакетов десятки, это и
 >> позволяет гибко комплектовать окончательные kernel-image с набором
 >> нужных фич. А для юзера собственно ничего не меняется - он берет
 >> понравившийся kernel-image и ставит себе. Не хочет задумываться -
 >> берет std. Зато потом начинаются бонусы - обновляется какая-нибудь
 >> alsa и это не повод для вытягивания нового ядра, апгрэйдится только
 >> один пакет, модуль перегрузил и все. Алса - это так, игрушки. А когда
 >> это, скажем, сетевые драйверы на продакшен сервере или еще что-нибудь
 >> такого же плана ?

 AF> Насколько удобно будет сборщикам собирать новые пакеты с драйверами и ядра.
Не знаю. Нужно попробовать. Но, вообще, для тех драйверов, которые
выкладываются производителями железа как раз такой подход и является
более прямым, их приходится точить для сборки в составе ядра.

 AF> Пример - выход ядра 2.4.21-финального. Как я понимаю сейчас процесс
 AF> сборки ядра будет выглядеть примерно так:

 AF> 1) Nidd собирает kernel-source и выкладывает
 AF> 2) Мантейнеры соответствующих патчей начинают портировать свои патчи
 AF> на новое ядро. До тех пор, пока все не запортируются - нет возможности
 AF> собрать std-sub ядро
Предлагаю назвать его kernel-image-common-тра-та-та и отразить этот
факт в полиси. В случае, если такая стратегия таки будет принята.

При переходе на новую версию сборка базы - это первоочередная задача
и все все бросают и точат свои патчи под новые сорцы. Если кто-то не
может, не успевает, то его патч подделают другие, не вижу тут проблем.

 AF> Тогда нам соответственно нужна будет таблица аля
 AF> ldetect-lst, в которой будет прописано, в каких пакетах -
 AF> какие модули.
 >> Не обязательно, если включить в ядро все железо. В виде зависимостей
 >> на пакеты с драйверами, а не собирать с ядром. По возможности, конечно.

 AF> Да. Понял. Но все-таки неплохо было бы иметь такую возможность -
 AF> ставить только те пакеты с драйверами, которые необходимы. Собственно
 AF> в инсталяторе есть сейчас такая штука, но она реализована в виде хаков
 AF> (прямо прописаны какие пакеты устанавливать если есть потребность в
 AF> определенном драйвере). Но от таблицы я бы не отказался - будет
 AF> хороший помошник для авторов kernel-image.
Возможно это и так. Но у меня пока нет идей как это грамотно сделать.

 >> А если гарантированно все пакеты с железом будут проставлены ?

 AF> Тогда проблем не возникнет. Вопрос тогда в том, какой виртуальный
 AF> пакет будет ставить все пакеты с железом и как сделать так, что бы все
 AF> пакеты с железом пападали в список зависимостей у виртуального
 AF> пакета. Желательно - автоматически ;-)
Можно. По названиям пакетов. Полуавтоматически :)

 >> Все модули ? И каждый раз при обновлении какого-либо драйвера этот
 >> архив пересобирать ? И ядро пересобирать ?

 AF> Нет, ядро не пересобирать.Пересобирается модуль и генерится некий файл
 AF> с описанием какие модули есть, каких ??? версий ???. Т.е. - фактически
 AF> репозитарий драйверов.

 >> И вытаскивать/устанавливать ?

 AF> Через сеть можно забирать только модули.
Тогда я не вижу принципиальных отличий от модулей в пакетах, кроме
размера. Но тут могут возникнуть другие проблемы, например с
взаимозависимостью модулей.

 AF> По поводу репозитария драйверов - это мысли вслух. Просьба тем, кто
 AF> считает это бредом - не комментировать. И так ясно, что  этот путь
 AF> сложен и необычен. Это как бы предложение по улучшению текущей
 AF> структуры.
Если не дробить столь мелко, то такой репозиторий - это все пакеты
kernel-module-drivers-... Чем плохо ?


-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy

[Anton Farygin]

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

Ed V. Bartosh пишет:
> Hello, Anton
> 
>  >> Это для сборщиков-комплектаторов ядер этих пакетов десятки, это и
>  >> позволяет гибко комплектовать окончательные kernel-image с набором
>  >> нужных фич. А для юзера собственно ничего не меняется - он берет
>  >> понравившийся kernel-image и ставит себе. Не хочет задумываться -
>  >> берет std. Зато потом начинаются бонусы - обновляется какая-нибудь
>  >> alsa и это не повод для вытягивания нового ядра, апгрэйдится только
>  >> один пакет, модуль перегрузил и все. Алса - это так, игрушки. А когда
>  >> это, скажем, сетевые драйверы на продакшен сервере или еще что-нибудь
>  >> такого же плана ?
> 
>  AF> Насколько удобно будет сборщикам собирать новые пакеты с драйверами и ядра.
> Не знаю. Нужно попробовать. Но, вообще, для тех драйверов, которые
> выкладываются производителями железа как раз такой подход и является
> более прямым, их приходится точить для сборки в составе ядра.

Да, для сторонних драйверов удобнее безусловно будет собирать. Проблемы 
будут возникать со сборкой новых версий основных ядер. Вопрос: будут ли 
в репозитарии жить ядра разных версий (и должны ли?)

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

> 
>  AF> Пример - выход ядра 2.4.21-финального. Как я понимаю сейчас процесс
>  AF> сборки ядра будет выглядеть примерно так:
> 
>  AF> 1) Nidd собирает kernel-source и выкладывает
>  AF> 2) Мантейнеры соответствующих патчей начинают портировать свои патчи
>  AF> на новое ядро. До тех пор, пока все не запортируются - нет возможности
>  AF> собрать std-sub ядро
> Предлагаю назвать его kernel-image-common-тра-та-та и отразить этот
> факт в полиси. В случае, если такая стратегия таки будет принята.
> 
> При переходе на новую версию сборка базы - это первоочередная задача
> и все все бросают и точат свои патчи под новые сорцы. Если кто-то не
> может, не успевает, то его патч подделают другие, не вижу тут проблем.

ok. Только все-таки это лучше внести в правила, что бы потом без обид ;-)

>  AF> ставить только те пакеты с драйверами, которые необходимы. Собственно
>  AF> в инсталяторе есть сейчас такая штука, но она реализована в виде хаков
>  AF> (прямо прописаны какие пакеты устанавливать если есть потребность в
>  AF> определенном драйвере). Но от таблицы я бы не отказался - будет
>  AF> хороший помошник для авторов kernel-image.
> Возможно это и так. Но у меня пока нет идей как это грамотно сделать.

Скриптом естественно.
  rpm --filesbypkg kernel-image-2.4.21pre5-std-up-2.4.21pre5-alt1|grep 
modules
Далее - убираем .o и путь к модулю. Получаем базу данных ;-)

> 
>  >> А если гарантированно все пакеты с железом будут проставлены ?
> 
>  AF> Тогда проблем не возникнет. Вопрос тогда в том, какой виртуальный
>  AF> пакет будет ставить все пакеты с железом и как сделать так, что бы все
>  AF> пакеты с железом пападали в список зависимостей у виртуального
>  AF> пакета. Желательно - автоматически ;-)
> Можно. По названиям пакетов. Полуавтоматически :)

Угумс. Тогда нужно будет соответственно отслеживать появление новых 
пакетов, содержащих модули и производить пересборку kernel-image.

> 
> 
>  >> И вытаскивать/устанавливать ?
> 
>  AF> Через сеть можно забирать только модули.
> Тогда я не вижу принципиальных отличий от модулей в пакетах, кроме
> размера. Но тут могут возникнуть другие проблемы, например с
> взаимозависимостью модулей.

ну это просто ;-)

> 
>  AF> По поводу репозитария драйверов - это мысли вслух. Просьба тем, кто
>  AF> считает это бредом - не комментировать. И так ясно, что  этот путь
>  AF> сложен и необычен. Это как бы предложение по улучшению текущей
>  AF> структуры.
> Если не дробить столь мелко, то такой репозиторий - это все пакеты
> kernel-module-drivers-... Чем плохо ?

В принципе без разницы. Но тогда нам нужно будет подробить помельче... 
;-) Например: драйвера по производителям kernel-drivers-net-intel, 
kernel-drivers-scsi-megaraid и т.д.

С дроблением замучаемся. ;-) Т.е. - получается двойная работа: 1) 
дробление kernel-image на мелкие пакеты 2) прописывание зависимостей 3) 
ведение базы <модуль> ->  <пакет>

Rgds,
Rider


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

Re: [d-kernel] kernel policy

[Ed V. Bartosh]

Hello, Anton

 >> Не знаю. Нужно попробовать. Но, вообще, для тех драйверов, которые
 >> выкладываются производителями железа как раз такой подход и является
 >> более прямым, их приходится точить для сборки в составе ядра.

 AF> Да, для сторонних драйверов удобнее безусловно будет
 AF> собирать. Проблемы будут возникать со сборкой новых версий основных
 AF> ядер. Вопрос: будут ли в репозитарии жить ядра разных версий (и должны
 AF> ли?)
Думаю да. Если на основе репозитария планируется собирать ядра для
разных дистрибутивов, то без этого не обойтись.

 AF> ставить только те пакеты с драйверами, которые необходимы. Собственно
 AF> в инсталяторе есть сейчас такая штука, но она реализована в виде хаков
 AF> (прямо прописаны какие пакеты устанавливать если есть потребность в
 AF> определенном драйвере). Но от таблицы я бы не отказался - будет
 AF> хороший помошник для авторов kernel-image.
 >> Возможно это и так. Но у меня пока нет идей как это грамотно сделать.

 AF> Скриптом естественно.
 AF> rpm --filesbypkg kernel-image-2.4.21pre5-std-up-2.4.21pre5-alt1|grep
 AF> modules

 AF> Далее - убираем .o и путь к модулю. Получаем базу данных ;-)
:) Грабли будут. Ладно, этот путь все равно не принимается для данного
репозитария, завязываем. Но по мне, так тут грабель просто поля будут.

 AF> пакет будет ставить все пакеты с железом и как сделать так, что бы все
 AF> пакеты с железом пападали в список зависимостей у виртуального
 AF> пакета. Желательно - автоматически ;-)
 >> Можно. По названиям пакетов. Полуавтоматически :)

 AF> Угумс. Тогда нужно будет соответственно отслеживать появление новых
 AF> пакетов, содержащих модули и производить пересборку kernel-image.
Да, но это уже будет решать мэнтейнер этого kernel-image.
Не хочет - не пересобирает.

 AF> В принципе без разницы. Но тогда нам нужно будет подробить
 AF> помельче... ;-) Например: драйвера по производителям
 AF> kernel-drivers-net-intel, kernel-drivers-scsi-megaraid и т.д.
Жизнь покажет, может даже и kernel-module-drivers-net-e100, полиси
не противоречит :)

 AF> С дроблением замучаемся. ;-) Т.е. - получается двойная работа: 1)
 AF> дробление kernel-image на мелкие пакеты 2) прописывание зависимостей
 AF> 3) ведение базы <модуль> ->  <пакет>
Результирующий kernel-image не дробиться будет, а составляться из
kernel-image-common и kernel-modules, или ты о другом ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy

[Peter Novodvorsky]

Anton Farygin <rider@altlinux.com> writes:

> В принципе без разницы. Но тогда нам нужно будет подробить
> помельче... ;-) Например: драйвера по производителям
> kernel-drivers-net-intel, kernel-drivers-scsi-megaraid и т.д.
>
> С дроблением замучаемся. ;-) Т.е. - получается двойная работа: 1)
> дробление kernel-image на мелкие пакеты 2) прописывание зависимостей
> 3) ведение базы <модуль> ->  <пакет>

Я прошу эту тему обсуждать в отдельном thread хотя бы, чтобы я могу
поставить на него scoring -5. На Антона scoring -5 я ставить не хочу.

Nidd.

-- 
Peter Novodvorsky                             nidd@myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!
           Kill 'em all, and let God sort 'em out

Re: [d-kernel] kernel policy

[aen]

Anton Farygin пишет:

> Ed V. Bartosh пишет:
>
>> Hello, Anton
>>  AF> Удобство эксплуатации - безусловно, важный момент. А о
>>  AF> каком удобстве _эксплуатации_ может идти речь, если
>>  AF> вместо одного пакета появляется десяток-другой ?
>> Это для сборщиков-комплектаторов ядер этих пакетов десятки, это и
>> позволяет гибко комплектовать окончательные kernel-image с набором
>> нужных фич. А для юзера собственно ничего не меняется - он берет
>> понравившийся kernel-image и ставит себе. Не хочет задумываться -
>> берет std. Зато потом начинаются бонусы - обновляется какая-нибудь
>> alsa и это не повод для вытягивания нового ядра, апгрэйдится только
>> один пакет, модуль перегрузил и все. Алса - это так, игрушки. А когда
>> это, скажем, сетевые драйверы на продакшен сервере или еще что-нибудь
>> такого же плана ?
>
>
> Насколько удобно будет сборщикам собирать новые пакеты с драйверами и 
> ядра.
>
> Пример - выход ядра 2.4.21-финального. Как я понимаю сейчас процесс 
> сборки ядра будет выглядеть примерно так:
>
> 1) Nidd собирает kernel-source и выкладывает
> 2) Мантейнеры соответствующих патчей начинают портировать свои патчи 
> на новое ядро. До тех пор, пока все не запортируются - нет возможности 
> собрать std-sub ядро 

Нет. Патчи std собирает главный мейнтейнер ядра.

>
> 3) После портирования патчей мантейнеры ядер начинают медленно и 
> упорно собирать собственно сами ядра (не забыть, что еще нужно всем 
> владельцам пакетов kernel-feat, входящим в kernel-image 
> запортироваться на новое ядро (если есть необходимость))
>
> Лично мне не очень нравится пункт 2, ибо тогда задержка с 
> портированием хоть одного мантейнера патча или функционала будет 
> держать всех остальных. Есть идеи, как это обойти ? Может быть 
> прописать в policy, что в случае задержек мантейнер ядра имеет право 
> пересобрать пакет с функционалом? 

Да.

>
>
>
>>
>>  AF> Необходимо будет поправить kudzu и инсталятор от MDK на
>>  AF> предмет использования этой таблицы при определении
>>  AF> устройств и установке пакетов.
>>
>>  AF> kudzu придется править достаточно сильно.
>> А если гарантированно все пакеты с железом будут проставлены ?
>
>
> Тогда проблем не возникнет. Вопрос тогда в том, какой виртуальный 
> пакет будет ставить все пакеты с железом и как сделать так, что бы все 
> пакеты с железом пападали в список зависимостей у виртуального пакета. 
> Желательно - автоматически ;-) 

Да, я об этом писал. Не знаю только, надо ли это включать в policy.

>
>

Rgrds, Алексей

Re: [d-kernel] kernel policy

[Dmitry V. Levin]

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

On Thu, Apr 17, 2003 at 02:14:34PM +0400, Anton Farygin wrote:
> Ed V. Bartosh пишет:
> >Hello, Anton
> > AF> Удобство эксплуатации - безусловно, важный момент. А о
> > AF> каком удобстве _эксплуатации_ может идти речь, если
> > AF> вместо одного пакета появляется десяток-другой ?
> >Это для сборщиков-комплектаторов ядер этих пакетов десятки, это и
> >позволяет гибко комплектовать окончательные kernel-image с набором
> >нужных фич. А для юзера собственно ничего не меняется - он берет
> >понравившийся kernel-image и ставит себе. Не хочет задумываться -
> >берет std. Зато потом начинаются бонусы - обновляется какая-нибудь
> >alsa и это не повод для вытягивания нового ядра, апгрэйдится только
> >один пакет, модуль перегрузил и все. Алса - это так, игрушки. А когда
> >это, скажем, сетевые драйверы на продакшен сервере или еще что-нибудь
> >такого же плана ?
> 
> Насколько удобно будет сборщикам собирать новые пакеты с драйверами и ядра.
> 
> Пример - выход ядра 2.4.21-финального. Как я понимаю сейчас процесс 
> сборки ядра будет выглядеть примерно так:
> 
> 1) Nidd собирает kernel-source и выкладывает
> 2) Мантейнеры соответствующих патчей начинают портировать свои патчи на 
> новое ядро. До тех пор, пока все не запортируются - нет возможности 
> собрать std-sub ядро
> 3) После портирования патчей мантейнеры ядер начинают медленно и упорно 
> собирать собственно сами ядра (не забыть, что еще нужно всем владельцам 
> пакетов kernel-feat, входящим в kernel-image запортироваться на новое 
> ядро (если есть необходимость))

Нет, не совсем так.

Поскольку у каждого kernel-image- свой maintainer, то именно он и
занимается сборкой этого пакета, с обновлением соответствующих
kernel-{fix,feat}.  Если у последних есть собственные maintainer'ы
(если и будут, то редко), то во взаимодействии с ними.

Сборкой внешних модулей для каждого kernel-image- (тех, которые вообще
применимы к соответствующим ядрам) занимаются maintainer'ы как этих
модулей, так и maintainer'ы kernel-image- (кто именно, зависит от взаимной
договорённости, по умолчанию - maintainer'ы внешних модулей).

Все согласны?


--
ldv

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

Re: [d-kernel] kernel policy

[Ed V. Bartosh]

Hello, Dmitry

 DVL> Нет, не совсем так.

 DVL> Поскольку у каждого kernel-image- свой maintainer, то именно он и
 DVL> занимается сборкой этого пакета, с обновлением соответствующих
 DVL> kernel-{fix,feat}.  Если у последних есть собственные maintainer'ы
 DVL> (если и будут, то редко), то во взаимодействии с ними.

 DVL> Сборкой внешних модулей для каждого kernel-image- (тех, которые вообще
 DVL> применимы к соответствующим ядрам) занимаются maintainer'ы как этих
 DVL> модулей, так и maintainer'ы kernel-image- (кто именно, зависит от взаимной
 DVL> договорённости, по умолчанию - maintainer'ы внешних модулей).

 DVL> Все согласны?
Я - да. 
Только хотел бы все-таки попробовать и схему с
kernel-image-common (vanilla+fixes+может еще что ?)
В этом случае для ядер, основаных на kernel-image-common
будет несколько другая схема, основанная прежде всего на 
сборке этого самого -common.

Или может я хочу странного ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy

[Peter Novodvorsky]

ed@altlinux.ru (Ed V. Bartosh) writes:

> Я - да. 
> Только хотел бы все-таки попробовать и схему с
> kernel-image-common (vanilla+fixes+может еще что ?)
> В этом случае для ядер, основаных на kernel-image-common
> будет несколько другая схема, основанная прежде всего на 
> сборке этого самого -common.
>
> Или может я хочу странного ?

common, -- это хорошо. Только, KMC получается придётся поддерживать
три ядра, -- std, vanilla и common. Не много ли?

Nidd.

-- 
Peter Novodvorsky                             nidd@myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!
           Kill 'em all, and let God sort 'em out

Re: [d-kernel] kernel policy

[Ed V. Bartosh]

Hello,

 >> Только хотел бы все-таки попробовать и схему с
 >> kernel-image-common (vanilla+fixes+может еще что ?)
 >> В этом случае для ядер, основаных на kernel-image-common
 >> будет несколько другая схема, основанная прежде всего на 
 >> сборке этого самого -common.
 >> 
 >> Или может я хочу странного ?

 PN> common, -- это хорошо. Только, KMC получается придётся поддерживать
 PN> три ядра, -- std, vanilla и common. Не много ли?

Я бы попробовал все-таки. Возможно из этого ничего не получится, тогда
само собой отомрет, будет видно, что оно не востребовано. 

Я не совсем ясно представляю, что туда должно
входить кроме фиксов и ванилы. xfs ? evms ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy

[aen]

Ed V. Bartosh пишет:

>Hello, Dmitry
>
> DVL> Нет, не совсем так.
>
> DVL> Поскольку у каждого kernel-image- свой maintainer, то именно он и
> DVL> занимается сборкой этого пакета, с обновлением соответствующих
> DVL> kernel-{fix,feat}.  Если у последних есть собственные maintainer'ы
> DVL> (если и будут, то редко), то во взаимодействии с ними.
>
> DVL> Сборкой внешних модулей для каждого kernel-image- (тех, которые вообще
> DVL> применимы к соответствующим ядрам) занимаются maintainer'ы как этих
> DVL> модулей, так и maintainer'ы kernel-image- (кто именно, зависит от взаимной
> DVL> договорённости, по умолчанию - maintainer'ы внешних модулей).
>
> DVL> Все согласны?
>Я - да. 
>Только хотел бы все-таки попробовать и схему с
>kernel-image-common (vanilla+fixes+может еще что ?)
>В этом случае для ядер, основаных на kernel-image-common
>будет несколько другая схема, основанная прежде всего на 
>сборке этого самого -common.
>
>Или может я хочу странного ?
>
>  
>
Думаю, да.
По крайней мере назовите это ядро иначе, например ed. std, common, -- 
только запутаемся.
Rgrds,  Алексей

Re: [d-kernel] kernel policy

[aen]

Dmitry V. Levin пишет:

>On Thu, Apr 17, 2003 at 02:14:34PM +0400, Anton Farygin wrote:
>  
>
>>Ed V. Bartosh пишет:
>>    
>>
>>>Hello, Anton
>>>AF> Удобство эксплуатации - безусловно, важный момент. А о
>>>AF> каком удобстве _эксплуатации_ может идти речь, если
>>>AF> вместо одного пакета появляется десяток-другой ?
>>>Это для сборщиков-комплектаторов ядер этих пакетов десятки, это и
>>>позволяет гибко комплектовать окончательные kernel-image с набором
>>>нужных фич. А для юзера собственно ничего не меняется - он берет
>>>понравившийся kernel-image и ставит себе. Не хочет задумываться -
>>>берет std. Зато потом начинаются бонусы - обновляется какая-нибудь
>>>alsa и это не повод для вытягивания нового ядра, апгрэйдится только
>>>один пакет, модуль перегрузил и все. Алса - это так, игрушки. А когда
>>>это, скажем, сетевые драйверы на продакшен сервере или еще что-нибудь
>>>такого же плана ?
>>>      
>>>
>>Насколько удобно будет сборщикам собирать новые пакеты с драйверами и ядра.
>>
>>Пример - выход ядра 2.4.21-финального. Как я понимаю сейчас процесс 
>>сборки ядра будет выглядеть примерно так:
>>
>>1) Nidd собирает kernel-source и выкладывает
>>2) Мантейнеры соответствующих патчей начинают портировать свои патчи на 
>>новое ядро. До тех пор, пока все не запортируются - нет возможности 
>>собрать std-sub ядро
>>3) После портирования патчей мантейнеры ядер начинают медленно и упорно 
>>собирать собственно сами ядра (не забыть, что еще нужно всем владельцам 
>>пакетов kernel-feat, входящим в kernel-image запортироваться на новое 
>>ядро (если есть необходимость))
>>    
>>
>
>Нет, не совсем так.
>
>Поскольку у каждого kernel-image- свой maintainer, то именно он и
>занимается сборкой этого пакета, с обновлением соответствующих
>kernel-{fix,feat}.  Если у последних есть собственные maintainer'ы
>(если и будут, то редко), то во взаимодействии с ними.
>
>Сборкой внешних модулей для каждого kernel-image- (тех, которые вообще
>применимы к соответствующим ядрам) занимаются maintainer'ы как этих
>модулей, так и maintainer'ы kernel-image- (кто именно, зависит от взаимной
>договорённости, по умолчанию - maintainer'ы внешних модулей).
>
>Все согласны?
>
>  
>
Я согласен.
2nidd: ждем новой версии policy.

Rgrds, Алексей

Re: [d-kernel] kernel policy

[Dmitry V. Levin]

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

On Thu, Apr 17, 2003 at 12:48:54PM +0400, Anton Farygin wrote:
> > AF> мне если честно не очень нравится идея сильного дробления
> > AF> ядра на модули. тяжело собирать, отслеживать зависимости,
> > AF> устанавливать и многое другое.  Тогда уж лучше
> > AF> реализовать мою идею с поставкой не упакованного в пакет
> > AF> ядра и спец. скриптом, устанавливающим только необходимые
> > AF> для данной машины модули.
> >Поясни, плз, поподробнее, я недопонял. Как это "не упакованного
> >в пакет" ?
> 
> Все модули идут не в пакете, а просто в архиве. Устанавливается не 
> пакет, а конкретный модуль, необходимый для поддержки устройства или 
> функциональности. Делается это достаточно простым скриптом.

Я категорически против любых предложений по включению в систему ПО не в
виде пакетов.

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


--
ldv

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

[JT] Re: [d-kernel] kernel policy

[Anton Farygin]

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

Dmitry V. Levin пишет:
> On Thu, Apr 17, 2003 at 12:48:54PM +0400, Anton Farygin wrote:
> 
>>>AF> мне если честно не очень нравится идея сильного дробления
>>>AF> ядра на модули. тяжело собирать, отслеживать зависимости,
>>>AF> устанавливать и многое другое.  Тогда уж лучше
>>>AF> реализовать мою идею с поставкой не упакованного в пакет
>>>AF> ядра и спец. скриптом, устанавливающим только необходимые
>>>AF> для данной машины модули.
>>>Поясни, плз, поподробнее, я недопонял. Как это "не упакованного
>>>в пакет" ?
>>
>>Все модули идут не в пакете, а просто в архиве. Устанавливается не 
>>пакет, а конкретный модуль, необходимый для поддержки устройства или 
>>функциональности. Делается это достаточно простым скриптом.
> 
> 
> Я категорически против любых предложений по включению в систему ПО не в
> виде пакетов.
> 
> Данное конкретное предложение, в частности, приведет к тому, что
> обновление ядра превратится в кошмар для пользователей и тех, кто эти
> обновления будет готовить.

:-)

Почему ? Я не вижу тут никакого кошмара. Ну да и я же просил - не 
комментировать если не согласен. Это не более чем мысли вслух.

Спорить не будем, ладно? Просто в последнее время я перестаю считать RPM 
удобным средством для распространения чего-либо, хоть немного отличного 
от приложений с нормальной архитектурой.

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

С ядром немного все иначе. Несомненно, что из этих самых 27M 
/lib/modules/2.4.21pre5-std-up-alt1 лично на моей машине необходимо 
всего мегабайт (если не меньше). Соответственно при выходе нового ядра 
мне (как и другим пользователям) приходится качать 10-15 мегабайт, 
вместо того, что бы скачать максимум 2 (включая /boot/vmlinuz). Сделать 
другую схему распространения мне кажется было бы интересно. Пускай даже 
параллельно с тем, что есть сейчас.

Rgds,
Rider



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

Re: [JT] Re: [d-kernel] kernel policy

[Ed V. Bartosh]

Hello, Anton

 AF> С ядром немного все иначе. Несомненно, что из этих самых 27M
 AF> /lib/modules/2.4.21pre5-std-up-alt1 лично на моей машине необходимо
 AF> всего мегабайт (если не меньше). Соответственно при выходе нового ядра
 AF> мне (как и другим пользователям) приходится качать 10-15 мегабайт,
 AF> вместо того, что бы скачать максимум 2 (включая
 AF> /boot/vmlinuz). Сделать другую схему распространения мне кажется было
 AF> бы интересно. Пускай даже параллельно с тем, что есть сейчас.

Я предлагаю компромисс - и в пакетах, и качать меньше нужно :)

-- 
Best regards,
Ed V. Bartosh

Re: [JT] Re: [d-kernel] kernel policy

[Anton Farygin]

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

Ed V. Bartosh пишет:
> Hello, Anton
> 
>  AF> С ядром немного все иначе. Несомненно, что из этих самых 27M
>  AF> /lib/modules/2.4.21pre5-std-up-alt1 лично на моей машине необходимо
>  AF> всего мегабайт (если не меньше). Соответственно при выходе нового ядра
>  AF> мне (как и другим пользователям) приходится качать 10-15 мегабайт,
>  AF> вместо того, что бы скачать максимум 2 (включая
>  AF> /boot/vmlinuz). Сделать другую схему распространения мне кажется было
>  AF> бы интересно. Пускай даже параллельно с тем, что есть сейчас.
> 
> Я предлагаю компромисс - и в пакетах, и качать меньше нужно :)
> 

В пакетах хорошо, но только в качестве эксперимента на каком-нить 
временном репозитарии.

Нужно тогда еще попробовать придумать скрипт для автоматического 
формирования списка пакетов с драйверами (и зависимостями).

Rgds,
Rider


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

Re: [JT] Re: [d-kernel] kernel policy

[Dmitry V. Levin]

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

On Thu, Apr 17, 2003 at 02:58:11PM +0400, Anton Farygin wrote:
> >>>AF> мне если честно не очень нравится идея сильного дробления
> >>>AF> ядра на модули. тяжело собирать, отслеживать зависимости,
> >>>AF> устанавливать и многое другое.  Тогда уж лучше
> >>>AF> реализовать мою идею с поставкой не упакованного в пакет
> >>>AF> ядра и спец. скриптом, устанавливающим только необходимые
> >>>AF> для данной машины модули.
> >>>Поясни, плз, поподробнее, я недопонял. Как это "не упакованного
> >>>в пакет" ?
> >>
> >>Все модули идут не в пакете, а просто в архиве. Устанавливается не 
> >>пакет, а конкретный модуль, необходимый для поддержки устройства или 
> >>функциональности. Делается это достаточно простым скриптом.
> >
> >Я категорически против любых предложений по включению в систему ПО не в
> >виде пакетов.
> >
> >Данное конкретное предложение, в частности, приведет к тому, что
> >обновление ядра превратится в кошмар для пользователей и тех, кто эти
> >обновления будет готовить.
> 
> :-)
> 
> Почему ? Я не вижу тут никакого кошмара. Ну да и я же просил - не 
> комментировать если не согласен. Это не более чем мысли вслух.

Этот список рассылки не предназначен для JT.
По крайней мере, таково моё убеждение.

> Спорить не будем, ладно? Просто в последнее время я перестаю считать RPM 
> удобным средством для распространения чего-либо, хоть немного отличного 
> от приложений с нормальной архитектурой.

С обсуждением этой философии, пожалуйста, в talk-room.


--
ldv

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

Re: [JT] Re: [d-kernel] kernel policy

[Anton Farygin]

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

Dmitry V. Levin пишет:
> On Thu, Apr 17, 2003 at 02:58:11PM +0400, Anton Farygin wrote:
> 
>>>>>AF> мне если честно не очень нравится идея сильного дробления
>>>>>AF> ядра на модули. тяжело собирать, отслеживать зависимости,
>>>>>AF> устанавливать и многое другое.  Тогда уж лучше
>>>>>AF> реализовать мою идею с поставкой не упакованного в пакет
>>>>>AF> ядра и спец. скриптом, устанавливающим только необходимые
>>>>>AF> для данной машины модули.
>>>>>Поясни, плз, поподробнее, я недопонял. Как это "не упакованного
>>>>>в пакет" ?
>>>>
>>>>Все модули идут не в пакете, а просто в архиве. Устанавливается не 
>>>>пакет, а конкретный модуль, необходимый для поддержки устройства или 
>>>>функциональности. Делается это достаточно простым скриптом.
>>>
>>>Я категорически против любых предложений по включению в систему ПО не в
>>>виде пакетов.
>>>
>>>Данное конкретное предложение, в частности, приведет к тому, что
>>>обновление ядра превратится в кошмар для пользователей и тех, кто эти
>>>обновления будет готовить.
>>
>>:-)
>>
>>Почему ? Я не вижу тут никакого кошмара. Ну да и я же просил - не 
>>комментировать если не согласен. Это не более чем мысли вслух.
> 
> 
> Этот список рассылки не предназначен для JT.
> По крайней мере, таково моё убеждение.

Хорошо. Больше ничего помечать как JT не буду.

>>Спорить не будем, ладно? Просто в последнее время я перестаю считать RPM 
>>удобным средством для распространения чего-либо, хоть немного отличного 
>>от приложений с нормальной архитектурой.
> 
> 
> С обсуждением этой философии, пожалуйста, в talk-room.

В talk-room я ничего не обсуждаю и ничего обусуждать не собираюсь.
Тем более схему распространения ядра.

Rgds,
Rider


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

Re: [d-kernel] kernel policy

[Michael Shigorin]

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

On Thu, Apr 17, 2003 at 12:48:54PM +0400, Anton Farygin wrote:
> Пример: у меня есть некая железка, неизвестного производителя.
> lspci сказал, что для нее неплохо было бы использовать драйвер
> noname.o, которого в стандартном ядре не оказалось. Вопрос -
> где искать этот драйвер?

Кстати, lspci$ALT было бы недурно выполнить понимающим, что одной
железке может соответствовать несколько наборов драйверов (пример
-- alsa/oss).

-- 
 ---- 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] kernel policy

[Dmitry V. Levin]

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

On Wed, Apr 16, 2003 at 06:31:06PM +0400, Ed V. Bartosh wrote:
>  a> от ядра и, соответственно, для установки новой версии пакета, собранной
>  a> с тем же ядром, заведомо не надо обновлять ядро. Это особенно полезно,
>  a> например, в случае фиксов alsa или новых версий nvidia.
>  >> 
>  >> То есть в случае других фиксов kernel-image будет пересобираться, а в
>  >> случае фиксов alsa нет ? То есть вынесение модуля в отдельный пакет
>  >> происходит исходя из частоты его обновления, я правильно понял ?
> 
>  a> Из асинхронности его обновления с обновлением ядра. Так
>  a> как в любом случае модуль пересобрать и скачать быстрее,
>  a> то что меняется чаще -- не суть важно.
> Понятно.
> 
> Я все-таки хочу дообсуждать тему отдельных пакетов с модулями.
> Можно рассмотреть 2 схемы:
> 1 - стратегия выноса в отдельные пакеты как можно большего количества
>     функционала. Плюсы здесь есть неоспоримые - ядро меньше, проще
>     апгрэйдить на продекшен системах (без перезагрузки), можно брать и
>     ставить только тот функционал, который нужен. 
>     Минусы тоже присутствуют, основной - большое количество пакетов, 
>     ведь их нужно будет собирать под конкретные ядра.
> 2 - противоположная стратегия - сборка как можно большего количества
>     модулей вместе с ядром, в составе kernel-image. Здесь с минусами и
>     плюсами все наоборот.
> 
> Истина где-то между этими двумя крайностями, IMHO. 
> А вот где, неплохо бы выяснить. Кто что скажет ?

Не вижу тут темы для обсуждения.  Все просто:
+ У нас есть модули, по перечисленным мной и aen'ом ранее причинам
  собираемые отдельно от ядра.
+ У нас есть разные kernel-image-, в состав каждого из которого входят
  собственно образ ядра и модули, собранные с ним одновременно.  Паковать
  часть _этих_ модулей отдельно не имеет смысла, если только мы не экономим
  дисковое пространство в /lib/modules/.
+ Других вариантов упаковки модулей нет.


--
ldv

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

Re: [d-kernel] kernel policy

[Ed V. Bartosh]

Hello, Dmitry

 DVL> Не вижу тут темы для обсуждения.  Все просто:
Это как кому :)

 DVL> + У нас есть модули, по перечисленным мной и aen'ом ранее причинам
 DVL> собираемые отдельно от ядра.
Да, это сейчас так. А завтра в зависимости от наших решений их будет больше
или меньше. Должна быть определена политика в этом вопросе, IMHO.
Вот тебе непридуманый пример:
[ed@pc213 SPECS]$ grep 'tar\.[bg]z' kernel24.spec |wc -l
     30
Среди этих трех десятков можно легко обнаружить вещи, которые могут
быть собраны (и собираются) в составе ядра и достаточно легко могут быть
собраны отдельно и вынесены в отдельные пакеты.
Вот о них я и веду речь. Куда их будем девать ? Это зависит от
принятой стратегии, которая должна быть отражена в полиси.
Я предлагаю - в отдельные пакеты.

 DVL> + У нас есть разные kernel-image-, в состав каждого из которого входят
 DVL> собственно образ ядра и модули, собранные с ним одновременно.  Паковать
 DVL> часть _этих_ модулей отдельно не имеет смысла, если только мы не экономим
 DVL> дисковое пространство в /lib/modules/.
Смысл есть. При сборке и поставке модулей отдельно увеличивается
вероятность того, что при апгрэйде не нужно будет переставлять все
ядро. Я об этом писал. И по-прежнему считаю, что это важно.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy

[Dmitry V. Levin]

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

On Thu, Apr 17, 2003 at 02:16:19PM +0400, Ed V. Bartosh wrote:
>  DVL> + У нас есть модули, по перечисленным мной и aen'ом ранее причинам
>  DVL> собираемые отдельно от ядра.
> Да, это сейчас так. А завтра в зависимости от наших решений их будет больше
> или меньше. Должна быть определена политика в этом вопросе, IMHO.

Ok, давай перечислим все эти (может, ещё есть) критерии, объявим, что
других нет, и внесем в policy.

> Вот тебе непридуманый пример:
> [ed@pc213 SPECS]$ grep 'tar\.[bg]z' kernel24.spec |wc -l
>      30
> Среди этих трех десятков можно легко обнаружить вещи, которые могут
> быть собраны (и собираются) в составе ядра и достаточно легко могут быть
> собраны отдельно и вынесены в отдельные пакеты.
> Вот о них я и веду речь. Куда их будем девать ? Это зависит от

По уже сформулированным критериям большинство этих модулей должно
собираться (и паковаться, естественно) отдельно от kernel-image-.

> принятой стратегии, которая должна быть отражена в полиси.
> Я предлагаю - в отдельные пакеты.

Тогда что мы обсуждаем? :)

>  DVL> + У нас есть разные kernel-image-, в состав каждого из которого входят
>  DVL> собственно образ ядра и модули, собранные с ним одновременно.  Паковать
>  DVL> часть _этих_ модулей отдельно не имеет смысла, если только мы не экономим
>  DVL> дисковое пространство в /lib/modules/.
> Смысл есть. При сборке и поставке модулей отдельно увеличивается
> вероятность того, что при апгрэйде не нужно будет переставлять все
> ядро. Я об этом писал. И по-прежнему считаю, что это важно.

Только непонятно, как собрать новые модули (те, которые собираются вместе
с kernel-image-), не собрав само ядро?


--
ldv

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

Re: [d-kernel] kernel policy

[Ed V. Bartosh]

Hello, Dmitry

 >> Вот тебе непридуманый пример:
 >> [ed@pc213 SPECS]$ grep 'tar\.[bg]z' kernel24.spec |wc -l
 >> 30
 >> Среди этих трех десятков можно легко обнаружить вещи, которые могут
 >> быть собраны (и собираются) в составе ядра и достаточно легко могут быть
 >> собраны отдельно и вынесены в отдельные пакеты.
 >> Вот о них я и веду речь. Куда их будем девать ? Это зависит от

 DVL> По уже сформулированным критериям большинство этих модулей должно
 DVL> собираться (и паковаться, естественно) отдельно от kernel-image-.
Отлично.

 >> принятой стратегии, которая должна быть отражена в полиси.
 >> Я предлагаю - в отдельные пакеты.

 DVL> Тогда что мы обсуждаем? :)
Именно это. Может есть другие мнения.

 DVL> + У нас есть разные kernel-image-, в состав каждого из которого входят
 DVL> собственно образ ядра и модули, собранные с ним одновременно.  Паковать
 DVL> часть _этих_ модулей отдельно не имеет смысла, если только мы не экономим
 DVL> дисковое пространство в /lib/modules/.
 >> Смысл есть. При сборке и поставке модулей отдельно увеличивается
 >> вероятность того, что при апгрэйде не нужно будет переставлять все
 >> ядро. Я об этом писал. И по-прежнему считаю, что это важно.

 DVL> Только непонятно, как собрать новые модули (те, которые собираются вместе
 DVL> с kernel-image-), не собрав само ядро?
Не знаю пока. И не считаю необходимым сейчас этим заниматься. Но
потом, когда первоначальная схема отработается, очень даже может
быть. Сейчас мне достаточно того, что то, что не входит
в vanilla будет выносится в отдельные пакеты.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy

[Michael Shigorin]

On Wed, Apr 16, 2003 at 06:31:06PM +0400, Ed V. Bartosh wrote:
> 1 - стратегия выноса в отдельные пакеты как можно большего количества
>     функционала. Плюсы здесь есть неоспоримые - ядро меньше, проще
>     апгрэйдить на продекшен системах (без перезагрузки), можно брать и
>     ставить только тот функционал, который нужен. 
>     Минусы тоже присутствуют, основной - большое количество пакетов, 
>     ведь их нужно будет собирать под конкретные ядра.

Кстати, PLD'шную схему рассматривали?  Она, как мне кажется, уже
прошла по этому пути.

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

Re: [d-kernel] kernel policy

[Ed V. Bartosh]

Hello, Michael

 >> 1 - стратегия выноса в отдельные пакеты как можно большего количества
 >> функционала. Плюсы здесь есть неоспоримые - ядро меньше, проще
 >> апгрэйдить на продекшен системах (без перезагрузки), можно брать и
 >> ставить только тот функционал, который нужен. 
 >> Минусы тоже присутствуют, основной - большое количество пакетов, 
 >> ведь их нужно будет собирать под конкретные ядра.

 MS> Кстати, PLD'шную схему рассматривали?  Она, как мне кажется, уже
 MS> прошла по этому пути.

Спасибо за наводку, посмотрел. Действительно, близкая стратегия.
Наша мне больше нравится, у них ориентация на единственное ядро,
поэтому и спеки на пакеты с модулями сделаны монолитными, вместе с
сорцами и сразу на модули для up и smp ядер. У нас это гибче сделано.

Я опять таки хочу вернуться к названиям, у них ядерные пакеты
называются предельно просто: 
имидж - kernel-2.2.22-6.i586.rpm, kernel-2.2.22-6.src.rpm
модуль - kernel-net-e100-2.1.15-3@2.2.22_6.i586.rpm, 
         kernel-net-e100-2.1.15-3@2.2.22_6.src.rpm

Интересно, как у них тогда решается проблема с установкой/апгрейдом ядер,
из-за которой у нас предлагается включать версию ядра в название пакета ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy

[Michael Shigorin]

On Fri, Apr 25, 2003 at 01:35:57PM +0400, Ed V. Bartosh wrote:
> Интересно, как у них тогда решается проблема с
> установкой/апгрейдом ядер, из-за которой у нас предлагается
> включать версию ядра в название пакета ?

Так может пойти и порасспрашивать?

Занялся бы, да, боюсь, тормозной из меня прокси до ужаса.

Вот поковырял pool ихний, 85 пакетов на рассмотрение/сравнение
получилось.  Из них десятка четыре стоит собрать (причем пару
десятков -- *стоит*).

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

Re: [d-kernel] kernel policy

[Ed V. Bartosh]

Hello,

 MS> On Fri, Apr 25, 2003 at 01:35:57PM +0400, Ed V. Bartosh wrote:
 >> Интересно, как у них тогда решается проблема с
 >> установкой/апгрейдом ядер, из-за которой у нас предлагается
 >> включать версию ядра в название пакета ?

 MS> Так может пойти и порасспрашивать?
Я как-то не нахожу в себе сил, да и apt/rpm не очень глубоко знаю. 

 MS> Занялся бы, да, боюсь, тормозной из меня прокси до ужаса.
Может таки попробуешь, а ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy

[Michael Shigorin]

On Fri, Apr 25, 2003 at 01:45:22PM +0400, Ed V. Bartosh wrote:
>  MS> Так может пойти и порасспрашивать?
>  MS> Занялся бы, да, боюсь, тормозной из меня прокси до ужаса.
> Может таки попробуешь, а ?

Петя -- оно надо или и так все ясно? :)

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

Re: [d-kernel] kernel policy

[Ed V. Bartosh]

Hello,

 MS> Занялся бы, да, боюсь, тормозной из меня прокси до ужаса.
 >> Может таки попробуешь, а ?

 MS> Петя -- оно надо или и так все ясно? :)

Пете может и ясно, он ничего страшного в названиях типа
kernel-image-2.4.21pre5-aw-up-2.4.21pre5-alt1.src.rpm не видит :)
А вот я ясности не наблюдаю пока. Тем более, что вот у того же PLD не так.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy

[Michael Shigorin]

On Fri, Apr 25, 2003 at 03:17:42PM +0400, Ed V. Bartosh wrote:
> Пете может и ясно, он ничего страшного в названиях типа
> kernel-image-2.4.21pre5-aw-up-2.4.21pre5-alt1.src.rpm не видит

Не, '(ну (это же) (была (шутка)))?

> :)

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

Re: [d-kernel] kernel policy

[Ed V. Bartosh]

Hello, Michael

 MS> On Fri, Apr 25, 2003 at 03:17:42PM +0400, Ed V. Bartosh wrote:
 >> Пете может и ясно, он ничего страшного в названиях типа
 >> kernel-image-2.4.21pre5-aw-up-2.4.21pre5-alt1.src.rpm не видит

 MS> Не, '(ну (это же) (была (шутка)))?

 >> :)

Да понял я. 
Тут опять генеральная линия поменялась, таких названий не будет. 
Почти :) Скоро увидите.
Но подход PLD все равно интересен.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy

[Ed V. Bartosh]

Hello, Peter

 n> kernel-patch-feat-%{upsteram_name}
 n> kernel-patch-fix-%{upstream_name}
 >> Предлагаю убрать patch- из названия:
 >> kernel-feat-%{upsteram_name}
 >> kernel-fix-%{upstream_name}
 >> 
 >> По-моему достаточно информативно и короче.

 PN> это не информативно. это не говорит, что это -- патч. Может ещё
 PN> -source- убрать?
Дык feat и fix будут говорить о том, что это патч, если уж так оно
надо. Только зачем, никак не пойму. Какая от этого польза знать что
это патч ? Давайте абстрагироваться :) Я вижу пакет
kernel-feat-security-rsback - мне обязательно знать, что это патч ?
Зачем ?


 >> И еще - а зачем вообще эти модули нужны ? Предлагаю избавиться от них
 >> или хотя бы минимизировать их количество. 
 >> Или описать здесь принципы выноса бинарных модулей в отдельный пакет. 
 >> Я как-то до сих пор их не уяснил :(

 PN> Это те модули которые уже вынесены. См. kernel-alsa-2.4.21pre-std-up
 PN> src rpm. Нет, не судьба называть их kernel-module.
По-моему сейчас строится новая схема сборки. И существующие
пакеты с бинарными модулями - это, возможно, анахронизм. С таким же
успехом можно оставить старый принцип сборки ядра, опираясь на то, что
такие ядра есть в Сизифе :) Где развитие ?
Я не предлагаю их безоговорочно убрать. Определите принципы по которым
будут создаваться такие пакеты. Принцип "потому, что так уже есть" мне
представляется слабым доказательством.

 n> 2. Versioning пакетов.
 n> ----------------------
 >> 
 n> Пакетам с feat патчами желательно присваивать версии, полученные из
 n> upstream. Если upstream не делает versioning, допустимо называть их по
 n> дате последнего изменения upstream в формате ddmmyy.
 >> 
 n> Пакетам с fix патчами обязательно присваивать версии по дате
 n> запаковывания в формате ddmmyy.
 >> Здесь можно привести формат имени таких пакетов.

 PN> secfixes. будут выглядеть именно так.
Не понял, сорри. Как "так" ? kernel-fix-security- а дальше ?
Нужно определить формат, как в случае с kernel-image, например.

 >> Вместе с патчами могут ставиться и тарболы, предлагаю их
 >> ставить в /usr/src/kernel/patches/src/<имя_патча>/
 >> В отдельный пакет с сорцами уж точно нет смысла это выносить.

 PN> Да, но то как патч распологает свои файлы, -- не дело полиси, в этом
 PN> разбирается скрипт apply.
Ты сам себе протифоречишь:
Патчи.
----------

/usr/src/patches/<имя_патча>/*            патчи
         patches/apply/<имя_патча>        программа, которая
                                          прикладывает патчи

Если не определить, где патчи будут хранить нужные им файлы - будет
путаница. А смысл ?

 >> 
 n> прикладывает патчи
 >> Считаю, что apply-программы вещь опциональная, а стандартное
 >> приложение патчей должно быть выполнено в виде макроса.
 >> Такой макрос уже есть.

 PN> Нет, не опциальная. Если нужно, -- можно сделать
 PN> /usr/lib/kernel-build-tools/apply, а все apply программы будут просто
 PN> соурсить этот файл.
Можно, конечно и так. Мне показалось более элегантным решить это с
помощью макроса. Давай я тебе его пришлю, а то так трудно
разговаривать ?
С помощью этого макроса я сейчас легко обхожусь без apply скриптов
в большинстве пакетов (xfs, secfixes, evms прикладываются без проблем).

 >> 
 n> Патчи внутри каталога могут находиться в любом расположении, это не
 n> определяется данным документом.
 >> Предлагаю определить, иначе будет затруднено вынесение общего
 >> функционала в макрос.

 PN> В среднем, будет один и тот же алгоритм. Но надо оставить за
 PN> патче-пакето-твроителями полную свободу в том, как и что патчить. 
Это путь к хаосу. Здесь, IMHO, лишняя свобода только вредит.
Что плохого в том, что при взгляде в каталог с патчами будет виден
порядок их приложения ?

 >> 
 n> Программа прикладывающая патч, будучи вызванная из каталога с исходными
 n> текстами ядра, обязана приложить к ним нужные патчи или возвратить 1 в
 n> случае ошибки прикладывания. Программа может пользоваться следующими
 n> переменными окружения заданными при запуске в среде:
 n> - APPLIED_PATCHES, переменная содержит список названий уже приложенных
 n> патчей через запятую.
 n> - KVER, версия ядра, к которой нужно приложить патч.
 >> Не уверен, что это нужно. 

 PN> Нужно. Почему не нужно?
Сорри, я немного неправильно выразился. KVER нужно, а APPLIED_PATCHES
и флажок ./patches/APPLIED_имя пакета дублируют друг друга.
Я думаю, что флаг более универсален и прост в проверке, к тому же
можно не только для пакета в целом его выставлять, а и для конкретных
патчей тоже, если понадобится. А с переменной возни больше, однозначно.

 >> 2. Пачти называются NN-название.patch, где NN определяет порядок приложения.
 >> устанавливаются в /usr/src/kernel/patches/название_пакета/

 PN> Это не регулируется policy.
Дык и напрасно :) Собственно, это только мои предложения, решать тебе.

 >> 3. Условное приложение патчей достигается путем установки
 >> патча в каталог /usr/src/kernel/patches/название_пакета/название_required_пакета
 >> Такой патч будет приложен только при условии того, что приложены
 >> патчи из пакета 'название_required_пакета'

 PN> Это рекоммендованный но не обязательный способ.
Согласен. Пусть будет рекомендательный. Это только первый шаг к 
условному приложению патчей. Мне порекомендовали, например, взглянуть
на PATCH-O-MATIC, там есть на что посмотреть в этом плане.
Может быть и есть смысл попользоваться их схемой.

 >> 4. При условии успешного приложения пакета патчей в каталоге ./patches
 >> соответствующего дерева kernel sources должен создаваться файл
 >> APPLIED_имя_пакета

 PN> Это рекоммендация.
См. выше.

 >> 5. Тарболы с сорцами, используемыми пакетом с патчами устанавливаются в 
 >> /usr/src/kernel/patches/src/название_пакета/

 PN> это рекоммендация.
Но, согласись, при такой схеме гораздо проще выяснить с какими файлами
работает пакет. Почему бы ее и не применять ?

 >> 6. Стандартные действия по установке патчей производятся с помощью
 >> макроса(ов) из пакета kernel-build-tools 

 PN> шелл-библиотеки из пакета kernel-build-tools, которая соурсится каждым
 PN> из apply-скриптов.
Я не против, в принципе. Но почему тебе так не нравится идея с
макросом ? Принципиальной разницы нет, IMHO.

 >> 7. Нестандартная действия по установке/приложению патчей производятся
 >> в скриптах имя_пакета-apply и устанавливаются в
 >> /usr/src/kernel/patches/apply

 PN> Не понимаю. Зачем делать условный оператор?
Чтобы избавиться в большинстве случаев от apply скриптов.

 >> 9. В репозитарии не должно быть бинарных пакетов с модулями, все
 >> модули должны находиться в соответствующем kernel-image

 PN> Нет. Все модули, которые могут собираться отдельно от ядра собираются
 PN> отдельно от ядра. как то: alsa, i2c, lm_sensors, и так далее,
 PN> см. сизиф.
См. Выше.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy

[aen]

Ed V. Bartosh пишет:

>Hello, Peter
>
> n> kernel-patch-feat-%{upsteram_name}
> n> kernel-patch-fix-%{upstream_name}
> >> Предлагаю убрать patch- из названия:
> >> kernel-feat-%{upsteram_name}
> >> kernel-fix-%{upstream_name}
> >> 
> >> По-моему достаточно информативно и короче.
>
> PN> это не информативно. это не говорит, что это -- патч. Может ещё
> PN> -source- убрать?
>Дык feat и fix будут говорить о том, что это патч, если уж так оно
>надо. Только зачем, никак не пойму. Какая от этого польза знать что
>это патч ? Давайте абстрагироваться :) Я вижу пакет
>kernel-feat-security-rsback - мне обязательно знать, что это патч ?
>Зачем ?
>
>
>
> >> И еще - а зачем вообще эти модули нужны ? Предлагаю избавиться от них
> >> или хотя бы минимизировать их количество. 
> >> Или описать здесь принципы выноса бинарных модулей в отдельный пакет. 
> >> Я как-то до сих пор их не уяснил :(
>
> PN> Это те модули которые уже вынесены. См. kernel-alsa-2.4.21pre-std-up
> PN> src rpm. Нет, не судьба называть их kernel-module.
>По-моему сейчас строится новая схема сборки. И существующие
>пакеты с бинарными модулями - это, возможно, анахронизм. С таким же
>успехом можно оставить старый принцип сборки ядра, опираясь на то, что
>такие ядра есть в Сизифе :) Где развитие ?
>Я не предлагаю их безоговорочно убрать. Определите принципы по которым
>будут создаваться такие пакеты. Принцип "потому, что так уже есть" мне
>представляется слабым доказательством.
>
Обе Ваши реплики в этом письме -- на одну тему. Если все "дополнения и 
исправления" -- патчи, то слово patch в имени пакета не обязательно.
Почему сохранение пакетов с модулями, которые собираются отдельно, мне 
предлставляется необходимым, я писал в прошлом письме.
Давайте обсудим.
nidd, насколько я понял, предложил принцип: все модули, не входящие в 
vanilla, которые могут быть собраны отдельно от пакета ядра, собираются 
отдельно.

Rgrds, Алексей

>  
>

Re: [d-kernel] kernel policy

[Ed V. Bartosh]

Hello,

 >> По-моему сейчас строится новая схема сборки. И существующие
 >> пакеты с бинарными модулями - это, возможно, анахронизм. С таким же
 >> успехом можно оставить старый принцип сборки ядра, опираясь на то, что
 >> такие ядра есть в Сизифе :) Где развитие ?
 >> Я не предлагаю их безоговорочно убрать. Определите принципы по которым
 >> будут создаваться такие пакеты. Принцип "потому, что так уже есть" мне
 >> представляется слабым доказательством.
 >> 
 a> Обе Ваши реплики в этом письме -- на одну тему. Если все "дополнения и
 a> исправления" -- патчи, то слово patch в имени пакета не обязательно.
В предложеной схеме наименования это именно так. Отсюда и мое предложение.

 a> Почему сохранение пакетов с модулями, которые собираются отдельно, мне
 a> предлставляется необходимым, я писал в прошлом письме.

 a> Давайте обсудим.
 a> nidd, насколько я понял, предложил принцип: все модули, не входящие в
 a> vanilla, которые могут быть собраны отдельно от пакета ядра,
 a> собираются отдельно.
Я, возможно, пропустил это предложение, мне казалось, что он как
раз делал упор на сборку модулей в основном вместе с kernel-image.

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

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy

[Peter Novodvorsky]

ed@altlinux.ru (Ed V. Bartosh) writes:

> Если все-таки это так, 

Так.

> тогда, во-первых: это нужно отразить в полиси и,

Главы о внешних модулях именно про такие пакеты.

> во-вторых: должен быть оговорен механизм, позволяющий собирать такие 
> модули и в составе некоторых kernel-images. Для таких вещей придется
> держать пакет с патчами и пакет с сорцами для сборки модуля отдельно.

Можно сделать пакет kernel-patch-feat-dev-alsa, который будет зависеть
от alsa-drivers-source и провязывать сборку alsa-drivers вместе с
ядром в своём apply скрипте.


-- 
Peter Novodvorsky                             nidd@myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!

Re: [d-kernel] kernel policy

[aen]

Hi!
Ed V. Bartosh пишет:

>Hello,
>
> >> По-моему сейчас строится новая схема сборки. И существующие
> >> пакеты с бинарными модулями - это, возможно, анахронизм. С таким же
> >> успехом можно оставить старый принцип сборки ядра, опираясь на то, что
> >> такие ядра есть в Сизифе :) Где развитие ?
> >> Я не предлагаю их безоговорочно убрать. Определите принципы по которым
> >> будут создаваться такие пакеты. Принцип "потому, что так уже есть" мне
> >> представляется слабым доказательством.
> >> 
> a> Обе Ваши реплики в этом письме -- на одну тему. Если все "дополнения и
> a> исправления" -- патчи, то слово patch в имени пакета не обязательно.
>В предложеной схеме наименования это именно так. 
>
Нет, так как есть модули.

>Отсюда и мое предложение.
>
> a> Почему сохранение пакетов с модулями, которые собираются отдельно, мне
> a> предлставляется необходимым, я писал в прошлом письме.
>
> a> Давайте обсудим.
> a> nidd, насколько я понял, предложил принцип: все модули, не входящие в
> a> vanilla, которые могут быть собраны отдельно от пакета ядра,
> a> собираются отдельно.
>Я, возможно, пропустил это предложение, мне казалось, что он как
>раз делал упор на сборку модулей в основном вместе с kernel-image.
>
>
>Если все-таки это так, тогда, во-первых: это нужно отразить в полиси и,
>во-вторых: должен быть оговорен механизм, позволяющий собирать такие 
>модули и в составе некоторых kernel-images.
>
Зачем?

> Для таких вещей придется
>держать пакет с патчами и пакет с сорцами для сборки модуля отдельно.
>
2nidd: мы уже занялись толкованием Вашего текста. Выразитесь яснее, 
пожалуйста.

Rgrds, Алексей

>
>  
>

Re: [d-kernel] kernel policy

[Ed V. Bartosh]

Hello,

 a> исправления" -- патчи, то слово patch в имени пакета не обязательно.
 >> В предложеной схеме наименования это именно так.

 a> Нет, так как есть модули.
Их я предлагал назвать -modules.
Это не принципиально, конечно, но мне кажется, что чем дальше термин
от sources, тем он большему количеству народа будет понятен :)

 a> nidd, насколько я понял, предложил принцип: все модули, не входящие в
 a> vanilla, которые могут быть собраны отдельно от пакета ядра,
 a> собираются отдельно.
 >> Я, возможно, пропустил это предложение, мне казалось, что он как
 >> раз делал упор на сборку модулей в основном вместе с kernel-image.
 >> 
 >> 
 >> Если все-таки это так, тогда, во-первых: это нужно отразить в полиси и,
 >> во-вторых: должен быть оговорен механизм, позволяющий собирать такие
 >> модули и в составе некоторых kernel-images.
 >> 
 a> Зачем?
Если я правильно понял, вопрос был 'зачем нужно собирать такие модули
в составе ядра ?' :)
Могу привести пример из жизни: в нашем дистрибутиве пришлось
внести XFS и EVMS в ядро, раньше они были в модулях.
В модулях они вели себя нестабильно. Не я этим занимался, поэтому не помню
точно каким образом, но факт это документальный.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy

[Dmitry V. Levin]

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

On Wed, Apr 16, 2003 at 11:44:27AM +0400, Ed V. Bartosh wrote:
> Hello, Peter
[...]
>  >> И еще - а зачем вообще эти модули нужны ? Предлагаю избавиться от них
>  >> или хотя бы минимизировать их количество. 
>  >> Или описать здесь принципы выноса бинарных модулей в отдельный пакет. 
>  >> Я как-то до сих пор их не уяснил :(
> 
>  PN> Это те модули которые уже вынесены. См. kernel-alsa-2.4.21pre-std-up
>  PN> src rpm. Нет, не судьба называть их kernel-module.
> По-моему сейчас строится новая схема сборки. И существующие
> пакеты с бинарными модулями - это, возможно, анахронизм. С таким же
> успехом можно оставить старый принцип сборки ядра, опираясь на то, что
> такие ядра есть в Сизифе :) Где развитие ?
> Я не предлагаю их безоговорочно убрать. Определите принципы по которым
> будут создаваться такие пакеты. Принцип "потому, что так уже есть" мне
> представляется слабым доказательством.

Почему нам все равно придётся иметь дело с модулями, собираемыми отдельно
от ядра:
+ Разные maintainer'ы.
  Maintainer того или иного ядра (kernel-image-) не может и не должен
  собирать все модули для этого ядра.  Сборка новой версии независимого
  модуля не должна приводить к необходимости пересобирать само ядро.
  Примеры: alsa, lm_sensors, drm, freeswan, nvidia, модемы, ...
+ Разные лицензии.
  Некоторые модули распространяются под несвободными лицензиями.
  По этой причине их нельзя паковать вместе со свободным ядром.
  Примеры: nvidia, модемы, ...

Так что это необходимо предусмотреть.


--
ldv

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

Re: [d-kernel] kernel policy

[Sergey Bolshakov]

>>>>> "Dmitry" == Dmitry V Levin <ldv@altlinux.org> writes:
[skipped]
 > Почему нам все равно придётся иметь дело с модулями, собираемыми отдельно
 > от ядра:
 > + Разные maintainer'ы.
 >   Maintainer того или иного ядра (kernel-image-) не может и не должен
 >   собирать все модули для этого ядра.  Сборка новой версии независимого
 >   модуля не должна приводить к необходимости пересобирать само ядро.
 >   Примеры: alsa, lm_sensors, drm, freeswan, nvidia, модемы, ...
 > + Разные лицензии.
 >   Некоторые модули распространяются под несвободными лицензиями.
 >   По этой причине их нельзя паковать вместе со свободным ядром.
 >   Примеры: nvidia, модемы, ...

 > Так что это необходимо предусмотреть.

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

Что касается несвободных модулей - их место в nonfree,
с соответствующим именем вроде kernel-nonfree-image-nvidia,
их поддержка в том или ином виде не должна мешать делать
Правильные Вещи :)

-- 

Re: [d-kernel] kernel policy

[aen]

Dmitry V. Levin пишет:

>On Wed, Apr 16, 2003 at 11:44:27AM +0400, Ed V. Bartosh wrote:
>  
>
>>Hello, Peter
>>    
>>
>[...]
>  
>
>> >> И еще - а зачем вообще эти модули нужны ? Предлагаю избавиться от них
>> >> или хотя бы минимизировать их количество. 
>> >> Или описать здесь принципы выноса бинарных модулей в отдельный пакет. 
>> >> Я как-то до сих пор их не уяснил :(
>>
>> PN> Это те модули которые уже вынесены. См. kernel-alsa-2.4.21pre-std-up
>> PN> src rpm. Нет, не судьба называть их kernel-module.
>>По-моему сейчас строится новая схема сборки. И существующие
>>пакеты с бинарными модулями - это, возможно, анахронизм. С таким же
>>успехом можно оставить старый принцип сборки ядра, опираясь на то, что
>>такие ядра есть в Сизифе :) Где развитие ?
>>Я не предлагаю их безоговорочно убрать. Определите принципы по которым
>>будут создаваться такие пакеты. Принцип "потому, что так уже есть" мне
>>представляется слабым доказательством.
>>    
>>
>
>Почему нам все равно придётся иметь дело с модулями, собираемыми отдельно
>от ядра:
>+ Разные maintainer'ы.
>  Maintainer того или иного ядра (kernel-image-) не может и не должен
>  собирать все модули для этого ядра.  Сборка новой версии независимого
>  модуля не должна приводить к необходимости пересобирать само ядро.
>  Примеры: alsa, lm_sensors, drm, freeswan, nvidia, модемы, ...
>+ Разные лицензии.
>  Некоторые модули распространяются под несвободными лицензиями.
>  По этой причине их нельзя паковать вместе со свободным ядром.
>  Примеры: nvidia, модемы, ...
>
>Так что это необходимо предусмотреть.
>
>  
>
Да, конечно.
Вопрос в формулировке соответствующего положения в policy.
Как и кем решается вопрос сборки модуля как отдельного пакета?
Может ли в некоторых случаях он быть собран в составе image, а в других 
-- отдельно?

Rgrds, Алексей

Re: [d-kernel] kernel policy

[Peter Novodvorsky]

Эд, привет.

ed@sam-solutions.net (Ed V. Bartosh) writes:

> Дык feat и fix будут говорить о том, что это патч, если уж так оно
> надо. Только зачем, никак не пойму. Какая от этого польза знать что
> это патч ? Давайте абстрагироваться :) Я вижу пакет
> kernel-feat-security-rsback - мне обязательно знать, что это патч ?
> Зачем ?

Да. Конечно. :) Зачем? Чтобы отличить его от пакетов с external
модулями типа kernel-alsa и kernel-drm.

> По-моему сейчас строится новая схема сборки. И существующие
> пакеты с бинарными модулями - это, возможно, анахронизм. С таким же
> успехом можно оставить старый принцип сборки ядра, опираясь на то, что
> такие ядра есть в Сизифе :) Где развитие ?
> Я не предлагаю их безоговорочно убрать. Определите принципы по которым
> будут создаваться такие пакеты. Принцип "потому, что так уже есть" мне
> представляется слабым доказательством.

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

>  PN> secfixes. будут выглядеть именно так.
> Не понял, сорри. Как "так" ? kernel-fix-security- а дальше ?
> Нужно определить формат, как в случае с kernel-image, например.

Нет. secfixes будут выглядеть как kernel-fix-security. А ide фиксы
будут выглядеть как kernel-fix-ide.

>  PN> Да, но то как патч распологает свои файлы, -- не дело полиси, в этом
>  PN> разбирается скрипт apply.
> Ты сам себе протифоречишь:

Я имел ввиду, то как пакет с патчами распологает свои файлы внутри его
каталога, -- не дело полиси.

> Если не определить, где патчи будут хранить нужные им файлы - будет
> путаница. А смысл ?

С внешней стороны путаницы не будет, так как всем этим будет управлять
программа apply.

>  PN> Нет, не опциальная. Если нужно, -- можно сделать
>  PN> /usr/lib/kernel-build-tools/apply, а все apply программы будут просто
>  PN> соурсить этот файл.
> Можно, конечно и так. Мне показалось более элегантным решить это с
> помощью макроса. Давай я тебе его пришлю, а то так трудно
> разговаривать ?

Давай.

>  PN> В среднем, будет один и тот же алгоритм. Но надо оставить за
>  PN> патче-пакето-твроителями полную свободу в том, как и что патчить. 
> Это путь к хаосу. Здесь, IMHO, лишняя свобода только вредит.

Главное, что внешний интерфейс фиксирован: программа apply. А то как
она действует, -- это дело разработчика. Можно написать helper,
который будут соурсить большинство apply скриптов.

> Что плохого в том, что при взгляде в каталог с патчами будет виден
> порядок их приложения ?

Если патч сделан грамотно, он и так будет виден. Это логично. Но
свободу реализации при условии сохранения интерфейса за разработчиком
оставлять надо.

>  PN> Нужно. Почему не нужно?
> Сорри, я немного неправильно выразился. KVER нужно, а APPLIED_PATCHES
> и флажок ./patches/APPLIED_имя пакета дублируют друг друга.

Да.

> Я думаю, что флаг более универсален и прост в проверке, к тому же
> можно не только для пакета в целом его выставлять, а и для конкретных
> патчей тоже, если понадобится. А с переменной возни больше,
> однозначно.

Согласен.

>  >> 2. Пачти называются NN-название.patch, где NN определяет порядок приложения.
>  >> устанавливаются в /usr/src/kernel/patches/название_пакета/
>
>  PN> Это не регулируется policy.
> Дык и напрасно :) Собственно, это только мои предложения, решать
> тебе.

У меня есть намерение, если ты не против, включить тебя в kernel
maintainer committee, когда ты станешь разработчиком, так что решать
таки *нам*.

> Согласен. Пусть будет рекомендательный. Это только первый шаг к 
> условному приложению патчей. Мне порекомендовали, например, взглянуть
> на PATCH-O-MATIC, там есть на что посмотреть в этом плане.
> Может быть и есть смысл попользоваться их схемой.

А PATCH-O-MATIC требует своего вида apply скриптов. Я и веду к тому,
что всё должно регулироваться внутри пакета.

>
>  >> 4. При условии успешного приложения пакета патчей в каталоге ./patches
>  >> соответствующего дерева kernel sources должен создаваться файл
>  >> APPLIED_имя_пакета
>
>  PN> Это рекоммендация.
> См. выше.

Предлагаю писать номер строчки или её обозначение в таких случаях. Но
я и так понял.

>  PN> это рекоммендация.
> Но, согласись, при такой схеме гораздо проще выяснить с какими файлами
> работает пакет. Почему бы ее и не применять ?

Потому, что если пэкэджер хороший, он сделает так, чтобы было просто
выяснить. А плохих у нас нет. :) И не будет.

>  PN> шелл-библиотеки из пакета kernel-build-tools, которая соурсится каждым
>  PN> из apply-скриптов.
> Я не против, в принципе. Но почему тебе так не нравится идея с
> макросом ? Принципиальной разницы нет, IMHO.

См. ниже [1].

>
>  >> 7. Нестандартная действия по установке/приложению патчей производятся
>  >> в скриптах имя_пакета-apply и устанавливаются в
>  >> /usr/src/kernel/patches/apply
>
>  PN> Не понимаю. Зачем делать условный оператор?
> Чтобы избавиться в большинстве случаев от apply скриптов.

[1]. Чем так помешали apply скрипты? apply скрипт, -- это интерфейс
доступа к патчу. И он фиксирован. Делать в таких случаях условный
оператор не очень красиво.



-- 
Peter Novodvorsky                             nidd@myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!

Re: [d-kernel] kernel policy

[Ed V. Bartosh]

Hello, Peter

 >> Дык feat и fix будут говорить о том, что это патч, если уж так оно
 >> надо. Только зачем, никак не пойму. Какая от этого польза знать что
 >> это патч ? Давайте абстрагироваться :) Я вижу пакет
 >> kernel-feat-security-rsback - мне обязательно знать, что это патч ?
 >> Зачем ?

 PN> Да. Конечно. :) Зачем? Чтобы отличить его от пакетов с external
 PN> модулями типа kernel-alsa и kernel-drm.
Их я предлагал называть kernel-module-alsa и т.п. 
По-моему термин module более понятен "конечному пользователю", чем
patch. Зачем людей пугать :)

 >> По-моему сейчас строится новая схема сборки. И существующие
 >> пакеты с бинарными модулями - это, возможно, анахронизм. С таким же
 >> успехом можно оставить старый принцип сборки ядра, опираясь на то, что
 >> такие ядра есть в Сизифе :) Где развитие ?
 >> Я не предлагаю их безоговорочно убрать. Определите принципы по которым
 >> будут создаваться такие пакеты. Принцип "потому, что так уже есть" мне
 >> представляется слабым доказательством.

 PN> В старой системе сборки все модули собирались из одного пакета и это
 PN> было очень плохо. В новой системе сборки, каждая подобная группа
 PN> модулей собирается из отдельного набора пакетов. Это позволяет
 PN> сборщику каждый раз не пересобирать всё при выходе новой версии группы
 PN> модулей, а пользователю не тащить каждый раз огроменный пакет из
 PN> сети. 
Очень хорошо. Но где принципы выноса какого-либо функционала в модуль ? 
Пока я вижу только принцип "потому, что так было".

 PN> secfixes. будут выглядеть именно так.
 >> Не понял, сорри. Как "так" ? kernel-fix-security- а дальше ?
 >> Нужно определить формат, как в случае с kernel-image, например.

 PN> Нет. secfixes будут выглядеть как kernel-fix-security. А ide фиксы
 PN> будут выглядеть как kernel-fix-ide.
А где будут даты, чето я нить теряю :( 
Я писал насчет отражения в полиси точного формата имен пакетов,
содержащих дату в своем имени.

 PN> Да, но то как патч распологает свои файлы, -- не дело полиси, в этом
 PN> разбирается скрипт apply.
 >> Ты сам себе протифоречишь:

 PN> Я имел ввиду, то как пакет с патчами распологает свои файлы внутри его
 PN> каталога, -- не дело полиси.
Почему ? Это, IMHO, привнесет некий порядок, который никому не
помешает, а выгода налицо - все лежит в предсказуемых местах.
А то завтра я тебе пришлю пакет, в котором тарбол поставлю в
/var/db/tarbals и буду с пеной у рта доказывать, что это не
противоречит полиси :)

 PN> Главное, что внешний интерфейс фиксирован: программа apply. А то как
 PN> она действует, -- это дело разработчика. Можно написать helper,
 PN> который будут соурсить большинство apply скриптов.

 >> Что плохого в том, что при взгляде в каталог с патчами будет виден
 >> порядок их приложения ?

 PN> Если патч сделан грамотно, он и так будет виден. Это логично. Но
 PN> свободу реализации при условии сохранения интерфейса за разработчиком
 PN> оставлять надо.
Я думаю, что требование или рекомендация положить тарбол в
определенное место и прибавить к названию патчей префикс, показывающий
порядок их приложения тоже никаким образом не ограничит свободу
реализации.


 >> >> 2. Пачти называются NN-название.patch, где NN определяет порядок приложения.
 >> >> устанавливаются в /usr/src/kernel/patches/название_пакета/
 >> 
 PN> Это не регулируется policy.
 >> Дык и напрасно :) Собственно, это только мои предложения, решать
 >> тебе.

 PN> У меня есть намерение, если ты не против, включить тебя в kernel
 PN> maintainer committee, когда ты станешь разработчиком, так что решать
 PN> таки *нам*.
Я не против, включай, разработчиком я уже стал.
Но в спорных вопросах как будем поступать ? Нужен третий, как минимум :)

 >> Согласен. Пусть будет рекомендательный. Это только первый шаг к 
 >> условному приложению патчей. Мне порекомендовали, например, взглянуть
 >> на PATCH-O-MATIC, там есть на что посмотреть в этом плане.
 >> Может быть и есть смысл попользоваться их схемой.

 PN> А PATCH-O-MATIC требует своего вида apply скриптов. Я и веду к тому,
 PN> что всё должно регулироваться внутри пакета.
А я к тому, что должна быть и общая политика, отраженная в полиси,
пусть даже рекомендательного характера.

 PN> это рекоммендация.
 >> Но, согласись, при такой схеме гораздо проще выяснить с какими файлами
 >> работает пакет. Почему бы ее и не применять ?

 PN> Потому, что если пэкэджер хороший, он сделает так, чтобы было просто
 PN> выяснить. А плохих у нас нет. :) И не будет.
Это эмоции чистой воды. Чтобы их не было и делается полиси.

 >> >> 7. Нестандартная действия по установке/приложению патчей производятся
 >> >> в скриптах имя_пакета-apply и устанавливаются в
 >> >> /usr/src/kernel/patches/apply
 >> 
 PN> Не понимаю. Зачем делать условный оператор?
 >> Чтобы избавиться в большинстве случаев от apply скриптов.

 PN> [1]. Чем так помешали apply скрипты? apply скрипт, -- это интерфейс
 PN> доступа к патчу. И он фиксирован. Делать в таких случаях условный
 PN> оператор не очень красиво.
Они не помешали. Но, возможно, в большинстве случаев они будут не
нужны. Зачем упражняться в Cut&Paste, когда можно эту энергию
направить на более полезные цели :) ? Например доведения 
макроса %apply_patches до универсального состояния :)

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy

[Dmitry V. Levin]

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

On Wed, Apr 16, 2003 at 02:15:16PM +0400, Ed V. Bartosh wrote:
>  >> Дык feat и fix будут говорить о том, что это патч, если уж так оно
>  >> надо. Только зачем, никак не пойму. Какая от этого польза знать что
>  >> это патч ? Давайте абстрагироваться :) Я вижу пакет
>  >> kernel-feat-security-rsback - мне обязательно знать, что это патч ?
>  >> Зачем ?
> 
>  PN> Да. Конечно. :) Зачем? Чтобы отличить его от пакетов с external
>  PN> модулями типа kernel-alsa и kernel-drm.
> Их я предлагал называть kernel-module-alsa и т.п. 
> По-моему термин module более понятен "конечному пользователю", чем
> patch. Зачем людей пугать :)

Т.е. мы будем называть пакеты с самими ядрами kernel-image-,
с модулями - kernel-module-,
c header'ами kernel-headers-,
с исходным кодом и патчами - kernel-(fix|feat)-?
Или как-то иначе?

Это несколько не так, как сложилось на данный момент, но ещё один раз
изменить схему ещё не поздно.  Однако после этого её необходимо будет
зафиксировать.

>  PN> В старой системе сборки все модули собирались из одного пакета и это
>  PN> было очень плохо. В новой системе сборки, каждая подобная группа
>  PN> модулей собирается из отдельного набора пакетов. Это позволяет
>  PN> сборщику каждый раз не пересобирать всё при выходе новой версии группы
>  PN> модулей, а пользователю не тащить каждый раз огроменный пакет из
>  PN> сети. 
> Очень хорошо. Но где принципы выноса какого-либо функционала в модуль ? 
> Пока я вижу только принцип "потому, что так было".

Речь не о том, какой функционал будет в модуле, а какой - в образе ядра.
Такие вещи не подлежат фиксированию в policy.

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

>  PN> У меня есть намерение, если ты не против, включить тебя в kernel
>  PN> maintainer committee, когда ты станешь разработчиком, так что решать
>  PN> таки *нам*.
> Я не против, включай, разработчиком я уже стал.
> Но в спорных вопросах как будем поступать ? Нужен третий, как минимум :)

Третьего я вам найду, об этом не беспокойтесь. :)


--
ldv

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

Re: [d-kernel] kernel policy

[Ed V. Bartosh]

Hello, Dmitry

 DVL> Т.е. мы будем называть пакеты с самими ядрами kernel-image-,
 DVL> с модулями - kernel-module-,
 DVL> c header'ами kernel-headers-,
 DVL> с исходным кодом и патчами - kernel-(fix|feat)-?
 DVL> Или как-то иначе?
Да, я предлагаю сделать так. Тут еще один плюс - в таком подходе мы
имеем только 6 категорий - фичи, фиксы, модули, сорцы, хедеры и
готовые ядра.
То есть катекория пакета однозначно определяется вторым элементом
названия (после kernel-). А в случае kernel-alsa и т.п. такой однозначной
категоризации нет. Убедил :) ?

 DVL> Это несколько не так, как сложилось на данный момент, но ещё один раз
 DVL> изменить схему ещё не поздно.  Однако после этого её необходимо будет
 DVL> зафиксировать.
Согласен.

 >> Очень хорошо. Но где принципы выноса какого-либо функционала в модуль ? 
 >> Пока я вижу только принцип "потому, что так было".

 DVL> Речь не о том, какой функционал будет в модуле, а какой - в образе ядра.
 DVL> Такие вещи не подлежат фиксированию в policy.
В полиси можно зафиксировать общую стратегию, применяемую в
репозитарии, пусть даже она будет носить рекомендательный характер.
Ведь полиси - это стратегический документ ?

 DVL> Модули, исходники которых живут и меняются асинхронно с самим ядром, имеет
 DVL> смысл собирать отдельно от ядра. Впрочем, я об этом уже говорил.
Да, поддерживаю.

 >> Но в спорных вопросах как будем поступать ? Нужен третий, как минимум :)

 DVL> Третьего я вам найду, об этом не беспокойтесь. :)
Ну вот и чудненько. Будем соображать на троих :)

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy

[aen]

Ed V. Bartosh пишет:

>Hello, Dmitry
>
> DVL> Т.е. мы будем называть пакеты с самими ядрами kernel-image-,
> DVL> с модулями - kernel-module-,
> DVL> c header'ами kernel-headers-,
> DVL> с исходным кодом и патчами - kernel-(fix|feat)-?
> DVL> Или как-то иначе?
>Да, я предлагаю сделать так. Тут еще один плюс - в таком подходе мы
>имеем только 6 категорий - фичи, фиксы, модули, сорцы, хедеры и
>готовые ядра.
>То есть катекория пакета однозначно определяется вторым элементом
>названия (после kernel-). А в случае kernel-alsa и т.п. такой однозначной
>категоризации нет. Убедил :) ?
>
Пожалуй, да.
nidd?

>
> DVL> Это несколько не так, как сложилось на данный момент, но ещё один раз
> DVL> изменить схему ещё не поздно.  Однако после этого её необходимо будет
> DVL> зафиксировать.
>Согласен.
>
> >> Очень хорошо. Но где принципы выноса какого-либо функционала в модуль ? 
> >> Пока я вижу только принцип "потому, что так было".
>
> DVL> Речь не о том, какой функционал будет в модуле, а какой - в образе ядра.
> DVL> Такие вещи не подлежат фиксированию в policy.
>В полиси можно зафиксировать общую стратегию, применяемую в
>репозитарии, пусть даже она будет носить рекомендательный характер.
>
Стратегия не должна быть рекомендательной.

Rgrds, Алексей

Re: [d-kernel] kernel policy

[Peter Novodvorsky]

ed@altlinux.ru (Ed V. Bartosh) writes:

> Hello, Dmitry
>
>  DVL> Т.е. мы будем называть пакеты с самими ядрами kernel-image-,
>  DVL> с модулями - kernel-module-,
>  DVL> c header'ами kernel-headers-,
>  DVL> с исходным кодом и патчами - kernel-(fix|feat)-?
>  DVL> Или как-то иначе?
> Да, я предлагаю сделать так. Тут еще один плюс - в таком подходе мы
> имеем только 6 категорий - фичи, фиксы, модули, сорцы, хедеры и
> готовые ядра.
> То есть катекория пакета однозначно определяется вторым элементом
> названия (после kernel-). А в случае kernel-alsa и т.п. такой однозначной
> категоризации нет. Убедил :) ?

Отлично-отлично. Наконец. Осталось решить последний вопрос: как будут назваться
пакеты с хедерами alsa?  :))) kernel-headers-alsa? [I}

Кстати я вношу с солгласия Эда и Димы патчик в kernel-policy:

 kernel policy обновляется участниками kernel maintainer committee.
 Состав kernel committee:
+- Ed Bartosh <ed@sam-solutions.net>
+- Dmitry Levin <ldv@altlinux.org>
 - Peter 'nidd' Novodvorsky <nidd@altlinux.com>
 
> В полиси можно зафиксировать общую стратегию, применяемую в
> репозитарии, пусть даже она будет носить рекомендательный характер.
> Ведь полиси - это стратегический документ ?

В качестве рекоммендации можно конечно.

>  DVL> Модули, исходники которых живут и меняются асинхронно с самим ядром, имеет
>  DVL> смысл собирать отдельно от ядра. Впрочем, я об этом уже говорил.
> Да, поддерживаю.

ура.

>  >> Но в спорных вопросах как будем поступать ? Нужен третий, как минимум :)
>
>  DVL> Третьего я вам найду, об этом не беспокойтесь. :)
> Ну вот и чудненько. Будем соображать на троих :)

См патчик :)

Остаются два ключевых вопроса:

1. Как прикладываются патчи (обязательность apply скрипта)
2. и [I]

Кажется всё, да?

Насчёт возможности собирания внешних модулей внутри ядра. В redhat
используется система с директорией add-on, в которую всё
кладётся. Можно, чтобы каждый source пакет (типа alsa-source) включал
в себя apply скрипт, который распаковывает его самого в add-on и
прописывает в Config.in себя. 

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

-- 
Peter Novodvorsky                             nidd@myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!
           Kill 'em all, and let God sort 'em out

Re: [d-kernel] kernel policy

[Ed V. Bartosh]

Hello, Peter

 PN> Кстати я вношу с солгласия Эда и Димы патчик в kernel-policy:

 PN> kernel policy обновляется участниками kernel maintainer committee.
 PN> Состав kernel committee:
 PN> +- Ed Bartosh <ed@sam-solutions.net>
 PN> +- Dmitry Levin <ldv@altlinux.org>
 PN> - Peter 'nidd' Novodvorsky <nidd@altlinux.com>
Согласен, спасибо.
А почему у всех e-mailы не @altlinux.ru ?
 
 >> В полиси можно зафиксировать общую стратегию, применяемую в
 >> репозитарии, пусть даже она будет носить рекомендательный характер.
 >> Ведь полиси - это стратегический документ ?

 PN> В качестве рекоммендации можно конечно.
Тут прозвучало и другое мнение :)

 DVL> Модули, исходники которых живут и меняются асинхронно с самим ядром, имеет
 DVL> смысл собирать отдельно от ядра. Впрочем, я об этом уже говорил.
 >> Да, поддерживаю.

 PN> ура.
Вот еще бы насчет базового ядра (только vanilla+fixes)
kernel-image-common что-нибудь в полиси написать ?

 PN> Остаются два ключевых вопроса:

 PN> 1. Как прикладываются патчи (обязательность apply скрипта)
Ну, мое предложение уже тут звучало :)

 PN> 2. и [I]
Это не принципиально. Пусть kernel-headers-alsa, по-моему понятно.

 PN> Кажется всё, да?
Про стратегию выноса в модули и kernel-image-common, если такое устраивает.

 PN> Насчёт возможности собирания внешних модулей внутри ядра. В redhat
 PN> используется система с директорией add-on, в которую всё
 PN> кладётся. Можно, чтобы каждый source пакет (типа alsa-source) включал
 PN> в себя apply скрипт, который распаковывает его самого в add-on и
 PN> прописывает в Config.in себя. 
А смысл их собирать внутри ядра ?

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

Да, предлагаю убрать из Сизифа все это безобразие и начать реализовывать
новую схему в Daedalus. После принятия полиси, разумеется.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy

[Dmitry V. Levin]

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

On Thu, Apr 17, 2003 at 01:35:39PM +0400, Peter Novodvorsky wrote:
> >  DVL> Т.е. мы будем называть пакеты с самими ядрами kernel-image-,
> >  DVL> с модулями - kernel-module-,
> >  DVL> c header'ами kernel-headers-,
> >  DVL> с исходным кодом и патчами - kernel-(fix|feat)-?
> >  DVL> Или как-то иначе?
> > Да, я предлагаю сделать так. Тут ещё один плюс - в таком подходе мы
> > имеем только 6 категорий - фичи, фиксы, модули, сорцы, хедеры и
> > готовые ядра.
> > То есть категория пакета однозначно определяется вторым элементом
> > названия (после kernel-). А в случае kernel-alsa и т.п. такой однозначной
> > категоризации нет. Убедил :) ?
> 
> Отлично-отлично. Наконец. Осталось решить последний вопрос: как будут назваться
> пакеты с хедерами alsa?  :))) kernel-headers-alsa? [I}

Например, так.

> Кстати я вношу с согласия Эда и Димы патчик в kernel-policy:

Может, обойдёмся без явного указания email'ов?

> >  DVL> Модули, исходники которых живут и меняются асинхронно с самим ядром, имеет
> >  DVL> смысл собирать отдельно от ядра. Впрочем, я об этом уже говорил.
> > Да, поддерживаю.
> 
> ура.

[...]

> Насчёт возможности собирания внешних модулей внутри ядра. В redhat

А зачем, особенно в свете процитированного выше?


--
ldv

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

Re: [d-kernel] kernel policy

[Sergey Pinaev]

hi.
On Thu, 17 Apr 2003 15:29:13 +0400
"Dmitry V. Levin" <ldv@altlinux.org> wrote:

DVL> Может, обойдёмся без явного указания email'ов?
Почему вас всех это так беспокоит?

-- 
mail="Sergey Pinaev <dfo@antex.ru>"
url="http://`echo $mail | sed 's/.* <\(.*\)>/\1/' | sed 's/@/./'`"

Re: [d-kernel] kernel policy

[aen]

Peter Novodvorsky пишет:

>
>Остаются два ключевых вопроса:
>
>1. Как прикладываются патчи (обязательность apply скрипта)
>2. и [I]
>
>Кажется всё, да?
>
2ldv&ed: скорейшее решение этих вопросов позволит разморозить сборку 
ядер :-)

Rgrds, Алексей

Re: [d-kernel] kernel policy

[aen]

nidd@myxomop.com пишет:

>Kernel Policy for Sisyphus.
>===========================
>
>Author: Peter Novodvorsky.
>
>
>0. Документ и его обновление.
>-----------------------------
>
>kernel policy обновляется участниками kernel maintainer committee.
>Состав kernel committee:
>- Peter 'nidd' Novodvorsky <nidd@altlinux.com>
>
>  
>
Не хватает раздела про правила включения разработчиков в этот comitee.

Rgrds, Алексей

[d-kernel] Re: kernel policy

[Vitaly Ostanin]

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

On Tue, 15 Apr 2003 18:40:45 +0400
nidd@myxomop.com wrote:

<skipped/>

> kernel-patch-feat-%{upsteram_name}
> kernel-patch-fix-%{upstream_name}

Если будет поддерживаться несколько веток ядра, IMHO, лучше
включать название ветки в названия пакетов
kernel22-*
kernel24-*

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

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

Re: [d-kernel] Re: kernel policy

[Peter Novodvorsky]

Vitaly Ostanin <vyt@vzljot.ru> writes:

> On Tue, 15 Apr 2003 18:40:45 +0400
> nidd@myxomop.com wrote:
>
> <skipped/>
>
>> kernel-patch-feat-%{upsteram_name}
>> kernel-patch-fix-%{upstream_name}
>
> Если будет поддерживаться несколько веток ядра, IMHO, лучше
> включать название ветки в названия пакетов
> kernel22-*
> kernel24-*

Нет. пакет с патчами содержит несколько разных вариантов патчей, а
apply скрипт решает какие из них прикладывать на основе $KVER, который
ему передаётся.

-- 
Peter Novodvorsky                             nidd@myxomop.com
   http://people.altlinux.ru/~nidd   Deadheads, unite!

Re: [d-kernel] kernel policy

[aen]

nidd@myxomop.com пишет:

>
>2. Versioning пакетов.
>----------------------
>
>Пакетам с feat патчами желательно присваивать версии, полученные из
>upstream. Если upstream не делает versioning, допустимо называть их по
>дате последнего изменения upstream в формате ddmmyy.
>
>Пакетам с fix патчами обязательно присваивать версии по дате
>запаковывания в формате ddmmyy.
>
>Пакеатам с внешними модулями и ядром, а так же с их исходными текстами
>желательно присваивать версии, полученные из upstream. Если upstream
>не делает versioning, допустимо называть их по дате последнего
>изменения upstream в формате ddmmyy. 
>
>  
>
1. s/ddmmyy/yyyymmdd/
2. Что будет, если одновременно выйдут патчи одного назначения к двум 
разным веткам ядер (2.2, 2.4, 2.5)?

Rgrds, Алексей

Re: [d-kernel] kernel policy

[Denis Smirnov]

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

On Tue, Apr 15, 2003 at 06:40:45PM +0400, nidd@myxomop.com wrote:

 > 
 > В пакетах feat содержатся патчи добавляющие ядру Linux новые
 > возможности. Это могут быть и драйверы устройств (рекоммендуется
 > называть такие kernel-patch-feat-dev-<имя_устройста>) и файловых
 > систем (желательно называть kernel-patch-feat-dev-<имя_файловой
                                                 ^^^
fs?

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

http://freesource.info

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

Re: [d-kernel] kernel policy

[Albert R. Valiev]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 324 bytes --]

В сообщении от 15 Апрель 2003 18:40 nidd@myxomop.com написал:

вопрос: когда пакеты с патчами, уже находящиеся в сизифе буду 
упорядочены в соотетствии с данным документом? :)


-- 

With Best Regards, Albert R. Valiev
------------------------------------
ALT Linux Team [www.altlinux.ru]
KDE Development Team [www.kde.org]

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

Re: [d-kernel] kernel policy

[Ed V. Bartosh]

Hello,

 ARV> вопрос: когда пакеты с патчами, уже находящиеся в сизифе буду 
 ARV> упорядочены в соотетствии с данным документом? :)

Дык еще обсуждение не закончено. Тут community или где :) ?
Я для себя принял это как драфт, над которым нужно работать.
Или это истина в последней инстанции :) ? Тады ой.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel policy

[aen]

Ed V. Bartosh пишет:

>Hello,
>
> ARV> вопрос: когда пакеты с патчами, уже находящиеся в сизифе буду 
> ARV> упорядочены в соотетствии с данным документом? :)
>
>Дык еще обсуждение не закончено. Тут community или где :) ?
>Я для себя принял это как драфт, над которым нужно работать.
>
Именно так.

Rgrds, Алексей

Re: [d-kernel] kernel policy

[aen]

Albert R. Valiev пишет:

>В сообщении от 15 Апрель 2003 18:40 nidd@myxomop.com написал:
>
>вопрос: когда пакеты с патчами, уже находящиеся в сизифе буду 
>упорядочены в соотетствии с данным документом? :)
>
>
>  
>
Нам надо как можно быстрее согласовать и принять policy. После этого 
надо сразу же пересобирать пакеты.
Предлагаю постараться закончить обсуждение сегодня.
Rgrds, Алексей

Re: [d-kernel] kernel policy

[Albert R. Valiev]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 991 bytes --]

В сообщении от 15 Апрель 2003 18:40 nidd@myxomop.com написал:


> Если upstream не делает versioning,
> допустимо называть их по дате последнего изменения upstream в
> формате ddmmyy.

Предлагаю для эстетичности (ну да, именно для того, чтобы версия 
выглядела более приятно) использовать дату, но разделенную 
точками по дням, месяцам и годам, т.е. к примеру пакету от 3-го 
апреля 2003 года при отсутствии upstream версии назначать версию 
03.04.03 (или 03.04.2003). ну это так, маленькое предложение.


> 3.1 Патчи.
> /usr/src/patches/<имя_патча>/*            патчи
>          patches/apply/<имя_патча>        программа, которая
>                                           прикладывает патчи

Дмитрий Левин предлагал переместить сами патчи в каталог 
/usr/src/kernel/patches. Мне это кажется разумным....

в остальном совершенно согласен :)

-- 

With Best Regards, Albert R. Valiev
------------------------------------
ALT Linux Team [www.altlinux.ru]
KDE Development Team [www.kde.org]

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

Re: [d-kernel] kernel policy

[Michael Shigorin]

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

On Wed, Apr 16, 2003 at 12:42:31PM +0400, Albert R. Valiev wrote:
> > /usr/src/patches/<имя_патча>/*            патчи

(скромно, но со вкусом -- Патчи ко Всем Исходникам...)

> Дмитрий Левин предлагал переместить сами патчи в каталог 
> /usr/src/kernel/patches. Мне это кажется разумным....

Мне одно покоя не дает -- как это согласуется с отсутствием в
/usr доступных по записи не-root объектов ФС?  Или сборка ядер
опять стала барским делом?

-- 
 ---- 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] kernel policy

[Sviatoslav Sviridov/Lintec Project]

On Fri, 25 Apr 2003 03:13:27 +0300
Michael Shigorin <mike@osdn.org.ua> wrote:

> 
> Мне одно покоя не дает -- как это согласуется с отсутствием в
> /usr доступных по записи не-root объектов ФС?  Или сборка ядер
> опять стала барским делом?

Вот-вот! Я тоже задаюсь вопросом как можно будет собирать ядра простым
смертным?

-- 
Sviatoslav Sviridov
[mailto:svd AT lintec.minsk.by] [ICQ#10845380] [Lintec Project] [MLUG]
--
Romance, like alcohol, should be enjoyed, but should not be allowed to
become necessary.
		-- Edgar Friedenberg

Re: [d-kernel] kernel policy

[Albert R. Valiev]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 867 bytes --]

В сообщении от 25 Апрель 2003 04:13 Michael Shigorin написал:
> On Wed, Apr 16, 2003 at 12:42:31PM +0400, Albert R. Valiev 
wrote:
> > > /usr/src/patches/<имя_патча>/*            патчи
>
> (скромно, но со вкусом -- Патчи ко Всем Исходникам...)
>
> > Дмитрий Левин предлагал переместить сами патчи в каталог
> > /usr/src/kernel/patches. Мне это кажется разумным....
>
> Мне одно покоя не дает -- как это согласуется с отсутствием в
> /usr доступных по записи не-root объектов ФС?  Или сборка ядер
> опять стала барским делом?

А в /usr никакого процесса сборки просиходить не будет.
Патчи, исходники и пр. распаковываются в ~/RPM/BUILD, там и 
собираются. 
В /usr/src будут лишь исходные тарболы ядра, драйверов и патчи.

-- 

With Best Regards, Albert R. Valiev
------------------------------------
ALT Linux Team [www.altlinux.ru]
KDE Development Team [www.kde.org]

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

Re: [d-kernel] kernel policy

[Sviatoslav Sviridov/Lintec Project]

On Fri, 25 Apr 2003 10:41:34 +0400
"Albert R. Valiev" <darkstar@altlinux.ru> wrote:

> В сообщении от 25 Апрель 2003 04:13 Michael Shigorin написал:
> > On Wed, Apr 16, 2003 at 12:42:31PM +0400, Albert R. Valiev 
> wrote:
> > > > /usr/src/patches/<имя_патча>/*            патчи
> >
> > (скромно, но со вкусом -- Патчи ко Всем Исходникам...)
> >
> > > Дмитрий Левин предлагал переместить сами патчи в каталог
> > > /usr/src/kernel/patches. Мне это кажется разумным....
> >
> > Мне одно покоя не дает -- как это согласуется с отсутствием в
> > /usr доступных по записи не-root объектов ФС?  Или сборка ядер
> > опять стала барским делом?
> 
> А в /usr никакого процесса сборки просиходить не будет.
> Патчи, исходники и пр. распаковываются в ~/RPM/BUILD, там и 
> собираются. 
> В /usr/src будут лишь исходные тарболы ядра, драйверов и патчи.

ага, и поэтому надо обладать правом установки пакетов в системе, чтобы
установить "лишь исходные тарболы ядра, драйверов и патчи"

-- 
Sviatoslav Sviridov
[mailto:svd AT lintec.minsk.by] [ICQ#10845380] [Lintec Project] [MLUG]
--
"Virtual" means never knowing where your next byte is coming from.

Re: [d-kernel] kernel policy

[Albert R. Valiev]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 516 bytes --]

В сообщении от 25 Апрель 2003 10:58 Sviatoslav Sviridov/Lintec 
Project написал:

> ага, и поэтому надо обладать правом установки пакетов в
> системе, чтобы установить "лишь исходные тарболы ядра,
> драйверов и патчи"

используйте BTE )))

к тому же какая разница? вам же все равно нужны права на 
установку пакетов, которые находятся в BuildReqires. это то же 
самое.

-- 

With Best Regards, Albert R. Valiev
------------------------------------
ALT Linux Team [www.altlinux.ru]
KDE Development Team [www.kde.org]

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

[d-kernel] Re: kernel policy

[Vitaly Ostanin]

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

On Tue, 15 Apr 2003 18:40:45 +0400
nidd@myxomop.com wrote:

<skipped/>

> 4. Порядок принятия новых пакетов в Sisyphus.
> ---------------------------------------------
> 
> Дабы упорядочить вхождение новых пакетов в Sisyphus, сначала
> разработчик обязан написать письмо в devel-kernel@altlinux.ru с
> темой ITP: <имя_пакета> (Intent to package) и с descriptionом
> пакета в теле, чтобы пояснить, что новое он хочет добавить.
> Далее проходит обсуждение этого пакета и люди договариваются,
> целесообразно ли присутствие пакета в Sisyphus. Kernel
> maintainer maintainer committee имеет право наложить вето на
> вхождение пакета в Sisyphus при согласии всех участников KMC.

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

Исключительно для комфорта устанавливающих :)

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

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

Re: [d-kernel] kernel policy

[Dmitry V. Levin]

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

On Tue, Apr 15, 2003 at 06:40:45PM +0400, nidd@myxomop.com wrote:
> 3.1 Патчи.
> ----------

Имена патчей должны соответствовать правилам, описанным в
alt-packaging/conventions


--
ldv

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