Здравствуйте. Сегодня на #altlinux имели место очередные прения. Лог прилагаю; по возможности извлеку из него ключевые моменты. Фактически обсуждалось: - каким (и когда) modutils быть в Sisyphus - важно ли, чтобы они были "как у всех". Мнение группы ab, UlfR, lioka, Grigory и вашего покорного слуги вкратце сводится к "надо, чтоб работало и поддерживалось; как у других -- дело десятое". Вывод -- взять modutils имени UlfR из people/ed/. Мнение rider (отчасти при поддержке vsu и со ссылками на ldv) рискну просуммировать как "нам вдруг стало небезразлично, как там что в Fedora и SuSE". Вывод -- тащить modutils из Fedora. Субъективно -- последнее выглядит интересным исключением из типично наблюдаемых в течение ряда последних лет тенденций развития Sisyphus как оригинального репозитория с вагоном know-how, из которого получаются удобные и выгодные в долговременной эксплуатации продукты. 2 ldv: какие проблемы с modutils-2.4.25-alt16? PS: субъективно -- "тащить федорино горе" есть безумие, потому как это вовсе не редхат, и бултыхаются они сейчас в проблемах нашей трехлетней давности, судя по fedora-package-announce@. Смотреть на них в таком системообразующем вопросе -- глупо и смешно. А отказываться от проверенного варианта в пользу концепт-кара с "простым" (нафигнужным) патчем -- безумие. --- vsu: надобы свести воедино modutils. Я таки добавил *.inputmap UlfR: дело в том, что в таком варианте может быть слишком много возни при обновлении как module-init-tools, так и modutils vsu: тогда какие предложения? UlfR: использовать кусок патча из fedora - depmod можно просто вызывать из module-init-tools vsu: Мы теряем главное -- макроязык vsu: он (м-и-т) вообще покоцанный, это не показатель. vsu: в м-и-т основная проблема в его мотто: "Я маленький такой, мне все остальное пофиг" ab: просто у меня возникает ощущение, что мы делаем что-то не то.. ab: чем больше мы будем вот так всё патчить, тем глубже мы будем вязнуть в этих патчах :( ab: очень не хотелось бы делать fork modutils ;-( rider: на обратном пути (через м-и-т) у тебя неумолимо получается форк м-и-т ab: а написание "modutils 2.5.x" так и сдохло? vsu: оно выродилось в то, что сделал Rusty ab: так пинайте автора mit, тем более патчи уже есть rider: еще раз: его пинать не надо. Он уже все в последнем абзаце нового modules.conf(5) все сказал rider: и я с ним согласен. ab: ты про то, что пускай все делают обертки сами ? он не занимается разработкой дистрибутивов, ему наши задачи и проблемы не интересны rider: в результате остается два пути: - развивать направление, начатое Глебом - сделать новые утилиты на базе m-i-t с втягиванием функционала из modutils Второй вариант, при грамотной реализации, может быть принят остальными вендорами. ab: давайте сделаем так: в Sisyphus сейчас пустим mit+modutils аля Fedora, ну и параллельно Глеб или кто-то из ваших ребят начнут продавливать автора modutils на включение патчей ? rider: нет, так не пойдет -- это глупо. rider: Я предлагаю пустить в Сизиф текущие наши modutils, а самим заняться разработкой нормального решения и обсуждением с остальными вендорами. ab: почему ? modutils из fedora вполне неплохой. rider: еще раз -- у него унифицированный макроязык для всех ядер? ab: ldv не пропускает ваши текущие modutils - слишком много вопросов у него по патчам. Т.е. - он сомневается что этот патч не ломает существующую функциональность rider: я не вижу от него вопросов по патчам. ab: а зачем нам нужна эта унификация ? ab: все равно мы попадаем на то, что у нас модули по другому называются.. не проще ли сделать обвязку над insmod/modprobe/rmmod, которая будет делать все так как нам надо ? rider: Ты постарайся оторваться от деталей нижнего уровня -- имен модулей, директорий и т.д. Подумай о другом: для пользователя разница между настройками двух веток ядер не оправдывается тем, что "разработчики в очередной раз усовершенствовали внутренности ядра". Пользователю плевать на это и я согласен с этим -- как бы не меняли реализацию, внешняя оболочка от этого страдать не должна. Более того, наш опыт показывает, что и не страдает -- мож но добиться унификации [skip] rider: я не говорю о lusers. Я говорю о пользователях, которыми являемся мы сами, администраторы крупных систем и т.д. rider: мне в данном случае интересен унифицированный подход для них, а не для тех, кто ничего читать не хочет, ничего не знает, и т.д. ab: аа.. понятно. для них все равно придется переучиваться на mit, ибо если мы сделаем не так как RH, SuSE и остальные - грабли будут у тех пользователей, кто переходит с SuSE на 2.6 на alt на 2.6 и наоборот ab: т.е. - унификация IMHO должна быть междистрибутивная, а не внутридистрибутивная. ab: я не понимаю, почему объединение функциональности не было сделано в SuSE, MDK или RH. rider: это следующий этап. Если наш подход себя оправдает (в чем я уверен), то его возьмут и остальные. rider: потому что они не делают appliances :) rider: на самом деле, я тебе при личной встрече могу рассказать почему. Не хочется говорить о их состоянии в дистрибутивных методиках на канале. ab: так давай сначала сделаем отдельную ветку (modutils-ng), сделаем для них сайт, добъемся выкладывания modutils-ng на ftp.kernel.org, а потом уже будем экспериментировать на наших пользователях ab: из того что ты сказал ясно одно - мы хотим как лучше, как круче... но не так как у всех. При этом зачем нужна эта крутизна - мне так и не понятно .. аргументы типа "так будет лучше пользователям" я не воспринимаю, ибо стандартом станет mit и все равно всем админам придется переучиваться (читай забыть старые параметры) rider: речь не идет о "как круче". Впрочем, я уже все сказал на эту тему -- не хочу ходить по кругам. решают те, кто саппортит. rider: я бы тогда вообще дистрибутив не делал. Все когда-нибудь в RH или Debian утрясется. именно, в итоге ab: согласен Тут я уже видел apt для RH. Ждем? :-) а 'майнстримового' саппорта не бывает. period rider: мне эти действия пока интересны тем, что больше так никто не делает, а потом идет по нашим же следам в своих дистрибутивах. Как только станет очевидно, что здесь уровень сопротивления выше того, который я могу себе позволить бороть, я отсюда уйду. Возможно вообще из дистрибутивов. gvy: ладно, зачем еще макроязык нужен ? rider, для поддержки уже имеющихся /etc/modules.conf (в уже имеющемся объеме оного языка) в течение жизненного цикла 2.4 gvy: ну так оно будет поддерживаться старыми modutils .. какие проблемы ? для _единообразной_ поддержки. rider, повреь -- мне чхать на "прихедших с suse/2.6" по одной простой причине: gvy: а где же ты тогда был, когда переименовывали conf.modules в modules.conf во всех дистрибутивах ? ты говоришь так, как будто уже есть suse/2.6 и там _сделан_ этот выбор; они будут или _знать_ про то, как это было с 2.4 (=> опытные), gvy: нет, а ты говоришь так, как будто мы уже сделали выбор и нам некуда дальше двигаться. или быть пыонерами из-за YaST, которым фиолетово (redhat-config, ...) так вот если говорить о переносе опыта -- то IMVCO более ценно в течение ближайших двух (минимум) лет gvy: я не понял про YaST сохранить опыт тех людей, которые в курсе про modules.conf и "как это с 2.4" [skip] rider, т.е. мы можем, _наоборот_, заявить, что у нас этот опыт сохранен и применим а эти идиоты полромали -- ну так это проблемы _их_ клиентов rider: между прочим, наш modutils, в отличие от еще не собраного федориного варианта, на сизифе уже обкатан. rider: что касается ldv, то пока что от него ни одного замечания по этим патчам нет. Как факт. rider, а где можно ознакомиться с претензиями ldv? в devel-kernel@ было? ab: верю, сам на нем сижу.. иди доказывай это ldv. gvy: а багов в том патче есть... как, впрочем, и в чистом mit vsu, баги всегда есть vsu: ошибки, как ты понимаешь, есть везде. Пуристами быть не приходится. -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/