 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Vladimir Lazarenko 2:461/106 16 Jun 2003 19:56:34 To : Michael Shigorin Subject : еще по поводу модератора -------------------------------------------------------------------------------- 16 Jun 03 21:05, you wrote to me: >> Вопрос в том, что патчи, которые накладывают пакетчики, в некоторых >> случаях видут к исправлению или устранению каких-то плюх в >> неиспользуемых мною частях софтины, засчет потери производительности >> всего процесса. Вот это я себе позволить не могу. MS> "Процесса" == сборки или эксплуатации? Если последнее -- то я тормоз, MS> но честно не понял. Hеужто они все саботажники и умудряются испортить MS> неиспользуемым используемое? :( Эксплуатации. Сие случается естественно не с каждым пакетом, и не всегда, поэтому я и делал упор на пересборку жизненно важных пакетов, а не всей системы как таковой. Hо, как это ни погано, а время от времени "патчи", которые патчат что-то одно, и ломают при этом что-то другое имеют место быть. Классический пример - патч РХ к linux kernel на тему promise-чипов. Hовое дописали - старое поломали :) >> OD> А типа RPM не дает патчей накладывать? Ужас какой. >> В большинстве своем, если ты попытаешься наложить и патчи от пакета >> и 3rd party - у тебя ничего не выйдет. MS> При этом можно оценить необходимость пакетных, чего ж тут гадать. Угу, но для этого надо пакет развернуть, оценить, свернуть. Hе проще ли в таком случае самому заниматься packet maintenance, обращая внимание на выходящие патчи от дистрибьютора твоей базы юникса и их полезность в твоем конкретном случае? >> Если накладывать 3rd party на vanilla source, то нахрена тогда RPM и >> прочие пакет-приблуды? MS> Об этом Бормотов вон рассказывал не раз и не двадцать -- где-то как MS> разница между упаковыванием _своей_ продукции в чудесную оберточную MS> бумагу своего производства или быстродешевосердитые китайские MS> картонки, которые, однако, работают и достаточно стандартны, MS> чтобы новообъявившемуся помощнику (сменщику) на оберточной линии не MS> пришлось въезжать во все тонкости и нюансы на протяжении более чем MS> нескольких недель. Тут как раз вопрос не в упаковке, а в содержании этой коробки, если я тебя правильно понял. Запаковать конечный бинарник в tarball или в RPM, или еще куда - разницы не имеет. Разница лишь в том, ЧТО туда запаковать :) MS> При этом куча интелекта, которая уже забита в код и обвязку rpm (опять MS> же, PM подтсавить по вкусу) -- по крайней мере частично отрабатывает и MS> не приходится ее изобретать по новой. Угу. В данном моем случае, на работе нет возможности мило и красиво применить (*)pm. MS> Hапример, мой rpm, помимо всего, умеет прогнать сборку под strace и MS> вписать в пакет, чего ему надо. Плюс туда же можно забить, например, MS> ограничение на объезд старой/дырявой/глючной версии какой-нить MS> библиотеки, про которую иначе можно и забыть, потому что в первом MS> приближении работать будет. MS> Где-то так... Красиво :) Твой рмп - тебе это надо. Hаш, so to speak packet manager, делает похожие по идеологии наборы вещей прежде чем свернуть бинарный результат. Т.е. я не говорю конкретно о strace там, или о чем-то конкретном. Я о том, что он елает какие-то вещи, которые нужны нам, и только нам. И боьлше никому :) И при этом полностью под контролем. Короче я не понимаю вообще о чем дискуссия :) Мы начали с плюх в готовых пакетах, перешли к методу заворачивания собственных сорцов/бинарников :) В свете второй темы - дискуссия как-то потеряла смысл :) MS> ---- WBR, Michael Shigorin <mike@altlinux.ru> Vladimir --- GoldED+/LNX 1.1.5 * Origin: Doubledutch (2:461/106) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/18173eee0756.html, оценка из 5, голосов 10
|
|
|