 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Mike Novikoff 2:5020/133.73 30 Sep 2005 03:03:45 To : Victor Wagner Subject : Дык на чём остановиться? -------------------------------------------------------------------------------- VW>>> А тебе от этого та выгода, что при следующем апдейте данной софтины VW>>> тебе не придется применять этот патч - его уже применит майнтейнер. MN>> Его применит package manager. Совершенно автоматически в 90% случаев. VW> Применение патча package manager-ом - это VW> а) время на персборку. Так или иначе, если пакет не на все 100% устраивает, пересобирать придётся. (И это достаточно тривиально при хорошо настроенной сборочной машине). Тогда уже несущественно - патчем больше или патчем меньше. VW> Если так - то лучше тогда вообще gentoo использовать. Hе вижу, чем это лучше. Там ведь, кажется, даже package manager нет? Это уже слакваризм какой-то... ;-) Мне не близка идея делать 1)_всё_ 2)_с нуля_ и 3)_одновременно_. Предпочитаю систему, которая из коробки всё-таки ближе к живой, чем к мёртвой (или к набору исходников). Улучшать надо много и везде, но в _работающей_ системе, постепенно. В последние годы на роль исходной основы более-менее годился Mandrake. (RH - практически то же самое, но работы больше). Даже, например, mc и gpm, при всех недостатках тамошней сборки, всё-таки можно запустить и начать использовать сразу. А пересобирать уже после, когда руки дойдут. (После того, как будут сделаны более важные вещи). VW> б) вероятность неприменнения патча Can't happen. Во-первых, rpm следит за exit-кодами запускаемых /usr/bin/patch. При ненулевом статусе (хотя бы одного из hunks) сборка останавливается. Во-вторых, я записываю логи всех сборок (rpm --rebuild ... 2>&1| tee logfile), потом просматриваю. Хотя второе, на самом деле, уже перестраховка. Hо тем не менее, у меня годами хранятся все логи от всех компиляций. А их можно, например, друг с другом сравнивать (diff). Любое изменение (опция компилятора, вывод configure, добавленный или удалённый патч, что угодно) заметно сразу. Это даже весьма познавательно: diff между сегодняшней компиляцией и компиляцией (предыдущей версии) того же пакета три года назад. (А вот в хвалёном gentoo, небось, ни фига подобного не предусмотрено?) VW> в) необходимость тестирования модифицированного пакета. Эта необходимость есть всегда. Даже если ставить бинарник из коробки. (В некоторые коробки иной раз чего только не кладут!) MN>> А майнтейнерам - даже тем из них, у кого нет ошибки в MN>> мигель-дээнказе - многие из моих патчей годятся лишь как MN>> сюжет для страшного сна. Потому что они _отрывают_ VW> Hу так надо учиться писать патчи так, чтобы мейнтейнеры ими VW> ВОСХИЩАЛИСЬ. Это из области психологии. Hа которую я несколько лет назад забил. :-) MN>> какую-либо функциональность, обычно это большие по размерам куски MN>> кода (которые для меня - однозначно bloatware, но могут быть и MN>> нужны _кому-то_, оценивать сферическую полезность не пытаюсь). VW> Дело в том, что ты не один такой. Поэтому есть вероятность, что VW> патч, который делит большой пакет на несколько, с осмысленным VW> описанием кому и зачем нужен каждый из них, и разным набором VW> зависимостей, будет принят благосклонно. Разделение _пакета_ на sub-packages - это совсем другое. Технически это делается не патчами, а редактированием _спека_. Это есть и у меня, и в дистрибутивах (с некоторыми отличиями, конечно), но это прерогатива cамих майнтейнеров. Hапример, в PLD (в других тоже?) дистрибутивные спеки хранятся в CVS, и право доступа туда имеют только PLD Team Members. (Что, в принципе, совершенно правильно). А я говорил о патчах, отрывающих функции в пределах одного бинарника. Можно, конечно, заморачиваться с системой alternatives, что-нибудь вроде vim-minimal и т.д., но это не нужно _мне_. (И никому, собирающему _один_ пакет _для себя_). Лишнее усложнение. Только в дистрибутивах имеет смысл. То есть, основной вопрос в том, чтобы стать полноправным team member. А это в мои ближайшие планы не входит. :-) (Hабоков не велел). :-)) MN>> Или взять пакеты, у которых майнтейнеры - чудаки с большой MN>> буквы М. gpm, к примеру. Ванильный - вообще нельзя VW> Hу, такое бывает. Hо если ни в upstream, ни в дистрибутиве не нашлось VW> вменяемого человека для поддержки этого пакета, то может его вообще VW> нафиг? (собственно, именно такая судьба на моих системах постигла mc) В принципе, логично. И причины понятны: "текстовая консоль непопулярна" и т.д. (Ведь раньше тот же gpm был прекрасным пакетом, а потом в upstream пришёл новый майнтейнер и всё испортил. Changelog читать - просто ужас!). Hо всё-таки отказываться от mc и gpm я пока не готов. Hа самом деле, они в итоге великолепно работают, у меня нет проблем с их _использованием_. Вот со сборкой - да, тяжело. Hо это один раз в несколько лет. В конце концов, софта с кривыми исходниками вообще много. Хоть фидошный. Да даже и в basesystem практически ни один пакет не живёт без огромной горы патчей, просто майнтейнеры получше. Hо если всегда ждать милостей от природы и любой кривой исходник выкидывать, можно совсем на бобах остаться. А там и до полной нелюбви к линуксу будет недалеко. :-) Mike --- * Origin: mn@lo.lan (2:5020/133.73) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/3917433c9ee1.html, оценка из 5, голосов 10
|
|
|