From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <40ACA1A2.7030908@l14.ru> Date: Thu, 20 May 2004 16:16:34 +0400 From: =?KOI8-R?Q?=E1=CC=C5=CB=D3=C5=CA_=EC=C0=C2=C9=CD=CF=D7?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.6) Gecko/20040310 X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: ALT Devel discussion list Subject: Re: [devel] =?KOI8-R?Q?=F0=CF=C4=C4=C5=D2=D6=CB=C1_=D0=D2=CF=D0?= =?KOI8-R?Q?=D2=C9=C5=D4=C1=D2=DD=C9=CE=D9_=D7_Sisyphus?= References: <40AB3BB1.4040302@altlinux.ru> <40AB5210.4000908@altlinux.com> <200405191902.47474.asy@altlinux.ru> <40AB6A95.9080501@altlinux.ru> <20040520103348.5338725b.vserge@altlinux.ru> <40AC6343.8060103@l14.ru> <40AC6C6C.8000806@altlinux.ru> <40AC8012.60802@l14.ru> <40AC84AA.8000901@altlinux.ru> In-Reply-To: <40AC84AA.8000901@altlinux.ru> X-Enigmail-Version: 0.83.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2004 12:16:37 -0000 Archived-At: List-Archive: List-Post: >> Поставьте себя на место девелопера. Невозможно собирать пакеты для >> всех. Должны быть какое то ограниченое количество стандартов а уж >> остальным придется как то поддерживать совместимость. > > > Да. К сожалению, LSB скорее мертв, чем жив. > ну так из этих сожалений должны быть выводы. осторожней надо плодить несовместимости и оглядываться на лидеров рынка, даже если они чего то делают "не в струю". >> Система проведения изменений в альт неприемлима для хоть сколько >> нибудь серьезных заказчиков. Серьезные заказчики в данном контексте, >> это все, кто хочет при любых обстоятельствах сохранять наработанное, >> готов добавлять свое и готов осваивать чужое, а не поставить и >> тыкаться по виджетам. Здесь уже было много истерик по поводу >> невозможности такой работы с альтом. > > > От серьезных заказчиков? будете смеятся - да. лично я не поднимал истерику только потому, что представляю себе достоинства и недостатки альта и не предлагаю его в тех случаях, когда может потребоваться что либо "извне". Фактически это все, что за пределами embeded (автономных готовых нерасширяемых решений) и oem в текущем виде (экономия средств). >> И во всех случаях присутствовала доля правды. Отсылки в платную >> поддержку решений ничего не доказывают. Еси в альте плюют на всех >> неальтовцев (свободных и не очень) в основном дереве, > > > Вот здесь -- подробнее, пожалуйста. > Где селеты спеков? Где документированные процедуры "как надо" по всем альт-зависимым вещам? Где забота о сборке сторонних приложений? Вам не нужны la - нет проблем. Оставьте из в devel-static и не ставьте их на время сборки - никто же слова не скажет. Нет, прибили все static да еще и в static все *.la вычистили. В итоге сборка статического пакета выливается в пересборку всех зависимостей с --enable-static и правкой спеков. Это называется нежная забота о сторонних пакетах и пользователях оных? Или это все борьба с проприетарщиной? Прямо на atmsk/linux-os выкладывать такую информацию некошерно, понимаю. А где это делается? И стоит ли после этого удивляться ругани в форумах на "глючность" альта. Никто ведь не обязан разглядывать config.log а далее макросы в /usr/lib/rpm чтобы понять, почему то, что собирается у всех без вопросов у нас стоит как вкопаное... > На самом деле, в этом менющемся мире надо искать свою нишу. Это уже вопрос внутрифирменый. Достаточно поставить в известность всех остальных о том,где же вы нашли свою нишу. Пока, вроде, везде. :) > Дистрибутив, поддерживающий проприетарщину -- ниша. Она будет > стремительно сокращаться. И даже если мы в нее просунем ногу -- завтра > нас оттуда выкинут. Здесь надо хладнокровно считать, чего я пока не > наблюдаю. Думайте о завтрашнем и послезавтрашнем дне, а не только о > сегодняшнем. Да чего вы зациклились на проприетарщине? Опенофис от зимиан, который я не в состоянии собрать, эта таже "проприетарщина". Есть же уже собраный под редхат, зачем его пересобирать? И таких пакетов много. А еще больше тех, которые не собираются из за "особенностей" сборки тех пакетов, на которые они опираются или просто из за "особенностей". > Одно из наших преимуществ -- близость к заказчику, который довольно > слабо верит в эфективную поддержку из-за океана. Мы можем работать для > конкретных, часто -- больших категорий потребителей. Я б сказал, один язык и одни проблемы. Поддержка из за океана _вообще_ обычно лучше. > Замахиватсья на все-все-все мы можем только в тесном взаимодействии с > каким-либо брендом. В общем, на мой взгляд, бить по площадям глупо. > то откуда появится уважение в остальных местах? >> >> А никто не говорит о "поддержке". Поддержка, это неправильное слово. >> Речь то идет о совместимости. А если этой совместимости нет в сизифе, >> то откуда она появится в дистрах? Еее же никто не проверял в то >> время, когда это надо было делать - в сизифе. > > > Ok. Давайте рассмотрим, каков может быть механизм такой проверки. Никакая проверка ничего не даст. Надо вносить изменения в процесс девелопмента сизифа. В нем, в этом метании и волюнтаризме вся несовместимость. Несовместимости возникают по нескольким причинам. 1) несовместимы версии библиотек 2) несовместимости внесеные в ядро или библиотеки патчами типа owl 3) несовместимости внесеные разными установками по умолчанию (например, лимиты в ядре или blowfish или tcb в паролях) 4) несовместимости внесеные реализацией - чруты, конфиги etc В процессе девелопмента постоянно возникают те или иные побуждения - отправить пинг в чрут, перевести cups под юзера, перепотрошить сборку постфикса, раздраконить питон, внедрить tcb, наложить owl на *std-up ядро. Почему бы прежде чем вносить такие изменения не проанонсировать их, не ответить на вопросы по тем или иным ситуациям, затем по результатм обсужждения принять решение о применимости этих изменений, затем задокументировать эти изменения и опубликовать вместе с рецептами решений возможных проблем и только потом прикладывать патчи? Такая процедура сняла бы тонну вопросов и несовместимостей... Ну и определиться с пределами своей компетенции. Разрезаный cups и blowfish по умолчанию явно эти пределы перешагнули. А механизм проверок уже есть. Багзилу никто не отменял. > > Хм. Не ко всякому из "народа" я хочу поворачиваться лицом. Да и "без > меня народ не полный". > Давайте все же сюда конкретику. > > Rgrds, Алексей > Вроде привнес.