On Mon, 16 Sep 2002 14:17:25 +0400 Serge wrote: Hi! > >Позволю себе суммировать правила бойцовского клуба: > >0. Vanilla kernel -- наше достояние и отправная точка. Keep tidy. Ес-но. > >1. Улучшать нужно только то, что не работает должным образом. Только для stable. > >2. Если не лезет, не вколачивай. Если вещь прошла п.1, то использовать. В крайнем случае посмотреть на другие варианты решения этой проблемы. Сам по себе этот пункт не имеет смысла и не соотносится с реальностью. > >3. От невыжатых 15% производительности ещё никто не умирал. Если > > кто-то умирает, пусть собирает ядро под себя. Только для stable. > >P.S. Я надеюсь, после некоторого обсуждения и обмозгования, > >сделать более серьёзный набросок kernel building policy. > > > Может быть так: > Ввести понятие patch_set > и в spec реализовать что-то вроде > $vanilla > | > +----- $minimal > | | > | +-- $with-some-funct1 > | | > | +-- $with-some-funct1+drivers-set1 > | +-- $with-some-funct1+drivers-set2 > | ......... > + $ALL_stable > | > + $ALL_stable_and_experimental > Это конечно сложно реализовать но зато можно получить из одного spec > любую функциональность > Для начала можно сделать хотя-бы $minimal $stable $advanced $tested Я не понимаю, зачем все нужно впихивать в один .spec, придумывать различные нестандартные схемы сборки и т.д., когда: а) проще (по крайней мере понятно как) сделать 2(3, 4) разных .spec б) оно уже и так сделано в разных .spec ? Надо понимать, что .spec от ядра и так непрост и доп. усложнение ему ИМХО ни к чему. > Regards, > Serge. -- Успехов, Konstantin