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

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

[Denis Ovsienko]

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


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

--
    DO4-UANIC

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

[Anton Farygin]

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

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

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

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

Rgds,
Rider

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

[Michael Shigorin]

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

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

JM$.02

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

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

[Ed V. Bartosh]

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

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

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

-- 
Best regards,
Ed V. Bartosh

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

[Ed V. Bartosh]

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

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

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

-- 
Best regards,
Ed V. Bartosh

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

[Sergey Vlasov]

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

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

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

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

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

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

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

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

[Ed V. Bartosh]

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

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

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

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

-- 
Best regards,
Ed V. Bartosh

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

[Anton Farygin]

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

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

Rgds,
Rider

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

[Denis Ovsienko]

>  >> Это другое дело. Зависимости на предоставляемое API должны быть, но
>  >> это не должны быть зависимости на модули или image.
>  >> Это может решаться именно таким образом - модуль или ядро будут
>  >> провайдить это. Нужно только более жестко оговорить формат и внести в полиси.
Оригинального автора этих строк я так и не нашёл, поэтому отвечаю тому, у
кого они появились впервые: я предлагал это сделать в августе или июле
применительно к CryptoAPI и EVMS. Предлагалось примерно следующее:
Provides: cryptoapi-kernelfeature
Provides: evms-kernelfeature
Provides: multicast-kernelfeature
Естественно, только в случае наложения соответствующих патчей и/или
включения нужных пунктов в конфиге ядра, с которым конкретный flavor
собирался. Попытаюсь сформулировать:
===
Если функциональность <name> ядра, от которой зависит
работоспособность других userspace пакетов, предоставляется не отдельным
пакетом kernel-modules, на который можно было бы указать зависимость, то
такое ядро должно предоставлять тэг <name>-kernelfeature, который и будет
прописываться в Requires соответствующим пакетам.
===
Кстати, разбег версий freeswan в ядре и в userspace можно было бы таким
образом ограничить.
Я думаю, это было бы правильно.

--
    DO4-UANIC

Re: [d-kernel] Re: [devel] Q: update kernel-policy (freeswan)

[Maxim Tyurin]

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

On Fri, Jan 23, 2004 at 05:41:34AM +0200, Denis Ovsienko wrote:
<scip>
> Кстати, разбег версий freeswan в ядре и в userspace можно было бы таким
> образом ограничить.
> Я думаю, это было бы правильно.

Кстати разбег версий freeswan в ближайшее время будет ликвидирован :)
Пакеты уже готовы. Остро нуждающиеся в рабочем freeswan могут взять
уже сейчас на
rsync://marla.pibhe.com/ftp/FreeSwan/SRPMS/

-- 

With Best Regards, Maxim Tyurin
JID:	MrKooll@jabber.pibhe.com
			

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

Re: [d-kernel] Re: [devel] Q: update kernel-policy (freeswan)

[Ed V. Bartosh]

 MT> Кстати разбег версий freeswan в ближайшее время будет ликвидирован :)
 MT> Пакеты уже готовы. Остро нуждающиеся в рабочем freeswan могут взять
 MT> уже сейчас на
 MT> rsync://marla.pibhe.com/ftp/FreeSwan/SRPMS/

А где-нибудь по ftp/http можно это взять ? 
А то из нашей тюрьмы не достать :(

Хочу посмотреть это на предмет интеграции c 2.6.
Есть ли какие мысли по этому поводу ? В смысле как это лучше сделать,
чтобы работало для обоих ядер ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] Re: [devel] Q: update kernel-policy (freeswan)

[Maxim Tyurin]

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

On Mon, Jan 26, 2004 at 07:23:53PM +0200, Ed V. Bartosh wrote:
> 
>  MT> Кстати разбег версий freeswan в ближайшее время будет ликвидирован :)
>  MT> Пакеты уже готовы. Остро нуждающиеся в рабочем freeswan могут взять
>  MT> уже сейчас на
>  MT> rsync://marla.pibhe.com/ftp/FreeSwan/SRPMS/
> 
> А где-нибудь по ftp/http можно это взять ? 
> А то из нашей тюрьмы не достать :(

Оно уже ушло в incoming
Должно скоро быть в Сизифе

> Хочу посмотреть это на предмет интеграции c 2.6.

Для 2.6 буду крутить freeswan 2.04 
С 2.4 совместимы freeswan начиная от 2.03

> Есть ли какие мысли по этому поводу ? В смысле как это лучше сделать,
> чтобы работало для обоих ядер ?

Я собрал super-freeswan т.к. думаю просто freeswan пойдет для 2.6
ядра.

Из патчей что составляют Super x509 патч уже рабочий.
alg патчи (поддержки алгоритмов шифрования) пока бэта но вроде не
падает (толково пока не тестировал).

ИМХО для ядра 2.4 оставить Super FReeS/WAN 1.99.8
для 2.6 делать 2.04 с x509 патчем 

Друг с другом они связываются без проблем если super пустить в generic
mode.

Такой вариант развития событий меня устраивает на все 100% 
может кто лучший предложит...
-- 

With Best Regards, Maxim Tyurin
JID:	MrKooll@jabber.pibhe.com
			

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

Re: [d-kernel] Re: [devel] Q: update kernel-policy (freeswan)

[Ed V. Bartosh]

 MT> Оно уже ушло в incoming
 MT> Должно скоро быть в Сизифе
Я вчера из дому вытащил таки - посмотрел, есть вопросы:
1. Откуда берется патч для ядра ? Если его можно получить из исходного
тарбола, то лучше было бы генерить kernel-feat из той же спеки, что и
остальные пакеты. Это обеспечит совместимость kernel user spase при
пересборках, не будет того безобразия, которое мы наблюдаем сейчас.

2. Почему в kernel-feat не используются макросы ? Я имею в виду
%sourse и %install_patches.

3. В FreeSWAN 2.04 лежит редхатовая спека, из которой они генерят
пакеты для юзерспейса и ядерный модуль. Можно ли аналогичный подход
использовать и нам ? То есть иметь минимум в kernel-feat и отдельно
генерить kernel-source, на основе которого собирать модули для разных ядер ?

4. Что это за ужасная конструкция для замены /etc/ipsec* на
/etc/freeswan/ipsec* ? Может хоть слегка подоптимизировать ?

5. Почему в kernel-feat нет урла ?

 >> Хочу посмотреть это на предмет интеграции c 2.6.

 MT> Для 2.6 буду крутить freeswan 2.04 
 MT> С 2.4 совместимы freeswan начиная от 2.03

 >> Есть ли какие мысли по этому поводу ? В смысле как это лучше сделать,
 >> чтобы работало для обоих ядер ?

 MT> Я собрал super-freeswan т.к. думаю просто freeswan пойдет для 2.6
 MT> ядра.

 MT> Из патчей что составляют Super x509 патч уже рабочий.
 MT> alg патчи (поддержки алгоритмов шифрования) пока бэта но вроде не
 MT> падает (толково пока не тестировал).

 MT> ИМХО для ядра 2.4 оставить Super FReeS/WAN 1.99.8
 MT> для 2.6 делать 2.04 с x509 патчем 
Поддерживаю. А под 2.6 freeswan может использовать алгоритмы, которые
в ядре ? Или ему тоже ALG патч нужен ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] Re: [devel] Q: update kernel-policy (freeswan)

[Maxim Tyurin]

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

On Tue, Jan 27, 2004 at 11:22:47AM +0200, Ed V. Bartosh wrote:
> 
>  MT> Оно уже ушло в incoming
>  MT> Должно скоро быть в Сизифе
> Я вчера из дому вытащил таки - посмотрел, есть вопросы:
> 1. Откуда берется патч для ядра ? Если его можно получить из исходного
> тарбола, то лучше было бы генерить kernel-feat из той же спеки, что и
> остальные пакеты. Это обеспечит совместимость kernel user spase при
> пересборках, не будет того безобразия, которое мы наблюдаем сейчас.

Я об этом уже думал. Патч получается из исходного тарбола и напильника.
Немного попозже сделаю сборку всех 3-х пакетов из одного src.rpm.
Я пока только учусь собирать rpm.

> 
> 2. Почему в kernel-feat не используются макросы ? Я имею в виду
> %sourse и %install_patches.

Я взял за основу те пакеты что были в Сизифе (кстати "ужасная
конструкция" тоже оттуда) и немного подправил.

> 
> 3. В FreeSWAN 2.04 лежит редхатовая спека, из которой они генерят
> пакеты для юзерспейса и ядерный модуль. Можно ли аналогичный подход
> использовать и нам ? То есть иметь минимум в kernel-feat и отдельно
> генерить kernel-source, на основе которого собирать модули для
> разных ядер ?

Было бы неплохо вообще-то. Но от kernel-source не так давно вообще
отказывались :)

> 
> 4. Что это за ужасная конструкция для замены /etc/ipsec* на
> /etc/freeswan/ipsec* ? Может хоть слегка подоптимизировать ?
> 
> 5. Почему в kernel-feat нет урла ?

Каюсь. Просто забыл.

> 
>  >> Хочу посмотреть это на предмет интеграции c 2.6.
> 
>  MT> Для 2.6 буду крутить freeswan 2.04 
>  MT> С 2.4 совместимы freeswan начиная от 2.03
> 
>  >> Есть ли какие мысли по этому поводу ? В смысле как это лучше сделать,
>  >> чтобы работало для обоих ядер ?
> 
>  MT> Я собрал super-freeswan т.к. думаю просто freeswan пойдет для 2.6
>  MT> ядра.
> 
>  MT> Из патчей что составляют Super x509 патч уже рабочий.
>  MT> alg патчи (поддержки алгоритмов шифрования) пока бэта но вроде не
>  MT> падает (толково пока не тестировал).
> 
>  MT> ИМХО для ядра 2.4 оставить Super FReeS/WAN 1.99.8
>  MT> для 2.6 делать 2.04 с x509 патчем 
> Поддерживаю. А под 2.6 freeswan может использовать алгоритмы, которые
> в ядре ? Или ему тоже ALG патч нужен ?

Конечно нужен ALG патч. Без него используется только 3DES и ничего
более. 
ALG есть под freeswan-2.x только пока в бэтах ходит.

Нет рабочего патча NAT, Dear Peer Detection, AggressiveMode,
selectors.


-- 

With Best Regards, Maxim Tyurin
JID:	MrKooll@jabber.pibhe.com
			

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

Re: [d-kernel] Re: [devel] Q: update kernel-policy (freeswan)

[Ed V. Bartosh]

 >> 2. Почему в kernel-feat не используются макросы ? Я имею в виду
 >> %sourse и %install_patches.

 MT> Я взял за основу те пакеты что были в Сизифе (кстати "ужасная
 MT> конструкция" тоже оттуда) и немного подправил.

Ясно. Я подправилю тогда и пришлю, ок ?

 >> 
 >> 3. В FreeSWAN 2.04 лежит редхатовая спека, из которой они генерят
 >> пакеты для юзерспейса и ядерный модуль. Можно ли аналогичный подход
 >> использовать и нам ? То есть иметь минимум в kernel-feat и отдельно
 >> генерить kernel-source, на основе которого собирать модули для
 >> разных ядер ?

 MT> Было бы неплохо вообще-то. Но от kernel-source не так давно вообще
 MT> отказывались :)

Это где такое было ? Вроде это основа текущей схемы.

 >>  MT> Из патчей что составляют Super x509 патч уже рабочий.
 >>  MT> alg патчи (поддержки алгоритмов шифрования) пока бэта но вроде не
 >>  MT> падает (толково пока не тестировал).
 >> 
 >>  MT> ИМХО для ядра 2.4 оставить Super FReeS/WAN 1.99.8
 >>  MT> для 2.6 делать 2.04 с x509 патчем 
 >> Поддерживаю. А под 2.6 freeswan может использовать алгоритмы, которые
 >> в ядре ? Или ему тоже ALG патч нужен ?

 MT> Конечно нужен ALG патч. Без него используется только 3DES и ничего
 MT> более. 
 MT> ALG есть под freeswan-2.x только пока в бэтах ходит.
Жаль. Но все равно нужно попробовать.


-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] Re: [devel] Q: update kernel-policy (freeswan)

[Maxim Tyurin]

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

On Tue, Jan 27, 2004 at 03:22:48PM +0200, Ed V. Bartosh wrote:
> 
>  >> 2. Почему в kernel-feat не используются макросы ? Я имею в виду
>  >> %sourse и %install_patches.
> 
>  MT> Я взял за основу те пакеты что были в Сизифе (кстати "ужасная
>  MT> конструкция" тоже оттуда) и немного подправил.
> 
> Ясно. Я подправилю тогда и пришлю, ок ?

Конечно. Я пока только учусь поэтому рад любой помощи и тыканью меня в
места требующие исправления (очень желательно с объяснениями как, что
и главное почему менять).

> 
>  >> 
>  >> 3. В FreeSWAN 2.04 лежит редхатовая спека, из которой они генерят
>  >> пакеты для юзерспейса и ядерный модуль. Можно ли аналогичный подход
>  >> использовать и нам ? То есть иметь минимум в kernel-feat и отдельно
>  >> генерить kernel-source, на основе которого собирать модули для
>  >> разных ядер ?
> 
>  MT> Было бы неплохо вообще-то. Но от kernel-source не так давно вообще
>  MT> отказывались :)
> 
> Это где такое было ? Вроде это основа текущей схемы.

Уже да :) Но такое было. И куча криков в comuunity@ "где kernel-source?"

> 
>  >>  MT> Из патчей что составляют Super x509 патч уже рабочий.
>  >>  MT> alg патчи (поддержки алгоритмов шифрования) пока бэта но вроде не
>  >>  MT> падает (толково пока не тестировал).
>  >> 
>  >>  MT> ИМХО для ядра 2.4 оставить Super FReeS/WAN 1.99.8
>  >>  MT> для 2.6 делать 2.04 с x509 патчем 
>  >> Поддерживаю. А под 2.6 freeswan может использовать алгоритмы, которые
>  >> в ядре ? Или ему тоже ALG патч нужен ?
> 
>  MT> Конечно нужен ALG патч. Без него используется только 3DES и ничего
>  MT> более. 
>  MT> ALG есть под freeswan-2.x только пока в бэтах ходит.
> Жаль. Но все равно нужно попробовать.

ALG у меня не падал за неделю тестирования. 
Мне остальных патчей хочется поэтому на 2.x пока не перехожу. 

-- 

With Best Regards, Maxim Tyurin
JID:	MrKooll@jabber.pibhe.com
			

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

Re: [d-kernel] Re: [devel] Q: update kernel-policy (freeswan)

[Ed V. Bartosh]

 >>  >> 2. Почему в kernel-feat не используются макросы ? Я имею в виду
 >>  >> %sourse и %install_patches.
 >> 
 >>  MT> Я взял за основу те пакеты что были в Сизифе (кстати "ужасная
 >>  MT> конструкция" тоже оттуда) и немного подправил.
 >> 
 >> Ясно. Я подправилю тогда и пришлю, ок ?

 MT> Конечно. Я пока только учусь поэтому рад любой помощи и тыканью меня в
 MT> места требующие исправления (очень желательно с объяснениями как, что
 MT> и главное почему менять).

Для начала тогда почитай новый вариант kernel-policy, его сюда недавно
Сергей Власов постил. Там и про макросы есть, и про все остальное :)

 >>  >> пакеты для юзерспейса и ядерный модуль. Можно ли аналогичный подход
 >>  >> использовать и нам ? То есть иметь минимум в kernel-feat и отдельно
 >>  >> генерить kernel-source, на основе которого собирать модули для
 >>  >> разных ядер ?
 >> 
 >>  MT> Было бы неплохо вообще-то. Но от kernel-source не так давно вообще
 >>  MT> отказывались :)
 >> 
 >> Это где такое было ? Вроде это основа текущей схемы.

 MT> Уже да :) Но такое было. И куча криков в comuunity@ "где kernel-source?"
Это было от непонимания :) 
Насчет freeswan - нужно попытаться как-то единообразно собрать 2.04 и
1.99, чтобы можно было легко использовать любой и под любым ядром.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] Re: [devel] Q: update kernel-policy (freeswan)

[Maxim Tyurin]

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

On Tue, Jan 27, 2004 at 04:14:10PM +0200, Ed V. Bartosh wrote:
> 
>  >>  >> 2. Почему в kernel-feat не используются макросы ? Я имею в виду
>  >>  >> %sourse и %install_patches.
>  >> 
>  >>  MT> Я взял за основу те пакеты что были в Сизифе (кстати "ужасная
>  >>  MT> конструкция" тоже оттуда) и немного подправил.
>  >> 
>  >> Ясно. Я подправилю тогда и пришлю, ок ?
> 
>  MT> Конечно. Я пока только учусь поэтому рад любой помощи и тыканью меня в
>  MT> места требующие исправления (очень желательно с объяснениями как, что
>  MT> и главное почему менять).
> 
> Для начала тогда почитай новый вариант kernel-policy, его сюда недавно
> Сергей Власов постил. Там и про макросы есть, и про все остальное :)

Для начала прочитал :)

> 
>  >>  >> пакеты для юзерспейса и ядерный модуль. Можно ли аналогичный подход
>  >>  >> использовать и нам ? То есть иметь минимум в kernel-feat и отдельно
>  >>  >> генерить kernel-source, на основе которого собирать модули для
>  >>  >> разных ядер ?
>  >> 
>  >>  MT> Было бы неплохо вообще-то. Но от kernel-source не так давно вообще
>  >>  MT> отказывались :)
>  >> 
>  >> Это где такое было ? Вроде это основа текущей схемы.
> 
>  MT> Уже да :) Но такое было. И куча криков в comuunity@ "где kernel-source?"
> Это было от непонимания :) 
> Насчет freeswan - нужно попытаться как-то единообразно собрать 2.04 и
> 1.99, чтобы можно было легко использовать любой и под любым ядром.

Я свое ИМХО на этот счет высказал:
Super FreeS/WAN 1.99.8 в ядро 2.4.x
FreeS/WAN 2.04+x509patch+ALGpatch в ядро 2.6.x

Между собой связываются нормально (правда на ядре 2.4 тестировал, но
разработчики пишут что у FreeS/WAN совместимость с ядром 2.6 просто
супер :)

А "любой под любым" не получится т.к. super на 2.6 не становится :(


-- 

With Best Regards, Maxim Tyurin
JID:	MrKooll@jabber.pibhe.com
			

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

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

[Anton Farygin]

On Fri, Jan 23, 2004 at 05:41:34AM +0200, Denis Ovsienko wrote:
> 
> >  >> Это другое дело. Зависимости на предоставляемое API должны быть, но
> >  >> это не должны быть зависимости на модули или image.
> >  >> Это может решаться именно таким образом - модуль или ядро будут
> >  >> провайдить это. Нужно только более жестко оговорить формат и внести в полиси.
> Оригинального автора этих строк я так и не нашёл, поэтому отвечаю тому, у
> кого они появились впервые: я предлагал это сделать в августе или июле
> применительно к CryptoAPI и EVMS. Предлагалось примерно следующее:
> Provides: cryptoapi-kernelfeature
> Provides: evms-kernelfeature
> Provides: multicast-kernelfeature
> Естественно, только в случае наложения соответствующих патчей и/или
> включения нужных пунктов в конфиге ядра, с которым конкретный flavor
> собирался. Попытаюсь сформулировать:
> ===
> Если функциональность <name> ядра, от которой зависит
> работоспособность других userspace пакетов, предоставляется не отдельным
> пакетом kernel-modules, на который можно было бы указать зависимость, то
> такое ядро должно предоставлять тэг <name>-kernelfeature, который и будет
> прописываться в Requires соответствующим пакетам.
> ===
> Кстати, разбег версий freeswan в ядре и в userspace можно было бы таким
> образом ограничить.
> Я думаю, это было бы правильно.

Нет, ибо apt заколбасит от этого дела - при попытке поставить любой пакет,
требующий cryptoapi-kernelfeathure будет поставлено первое по алфавиту
ядро.

Rgds,
Rider

[d-kernel] *-kernelfeature

[Denis Ovsienko]

> Нет, ибо apt заколбасит от этого дела - при попытке поставить любой пакет,
> требующий cryptoapi-kernelfeathure будет поставлено первое по алфавиту
> ядро.
Нельзя поступить как с ядрами в M2.2? Остановиться и попросить уточнить.
Или поставить первое по алфавиту. Если кто не согласен, то пусть
заблаговременно себе поставит подходящее нужной ветки и версии.

--
    DO4-UANIC