From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: ** X-Spam-Status: No, score=2.9 required=5.0 tests=BAYES_50,DNS_FROM_OPENWHOIS, FUZZY_XPILL autolearn=no version=3.2.5 Date: Sun, 20 Mar 2011 15:46:56 +0200 From: Michael Shigorin To: devel@lists.altlinux.org Message-ID: <20110320134656.GT23409@osdn.org.ua> Mail-Followup-To: devel@lists.altlinux.org References: <20110320062054.1D967218217F@ssh.git.altlinux.org> <20110320121930.GP23409@osdn.org.ua> <20110320123059.GC1698@altlinux.org> <20110320130236.GQ23409@osdn.org.ua> <20110320132627.GD1698@altlinux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110320132627.GD1698@altlinux.org> User-Agent: Mutt/1.4.2.1i Subject: Re: [devel] =?koi8-r?b?YXRALCDOxSDMz83ByiDTydrJxg==?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 13:47:01 -0000 Archived-At: List-Archive: List-Post: On Sun, Mar 20, 2011 at 04:26:27PM +0300, Alexey Tourbin wrote: > > (похоже, раньше libcurl-devel или libldap-devel вытягивал > > libssl-devel) > Да, libcurl-devel требовал libssl-devel, причем эта зависимость была > указана в спекфайле вручную. OpenSSL используется только в реализации, > а на уровне API никак не упоминается. Поэтому я всего лишь убрал > лишнюю зависимость из спекфайла, вследствие чего пакет libcurl-devel > стал лучше. Обидно слышать, что я ломаю сизиф. А с майнтейнером не советовался, из каких соображений он туда эту зависимость прописывал руками? Может, дело не в формальном API, а ещё и в сложившейся практике?.. Мне тоже обидно такое говорить, но лучше сказать, чем будешь думать, что от этого изменения пакет стал лучше, а это не так (http://egorfine.com/ru/articles/worse-than-failure/). > Я не отслеживаю возникновение "урезанных конфигураций" такого > рода, просто нашёл первый подходящий для примера лог сборки. > В принципе вся информация открыта. Лёш, ну ты ж понимаешь, что это "в принципе" как мёртвому припарки. У нас вон куча открытых отчётов repocop, а многие люди наступают на описанные там грабли -- файловые конфликты те же. Стоит делать так, чтоб использовать репозиторий и работать над ним было удобно. Времени и так не хватает ни на что, а ты его предлагаешь потратить его на анализ неформализованных данных и даже не говоришь, ради чего. По-моему, подобная минимизация сборочных зависимостей имеет ровно одно преимущество: облегчение сборочного чрута при прочих равных. Но само по себе это времени людей не стоит -- смотри, в случае того же strongswan получилось так: - ты потратил время на оптимизатор в buildreq; - я потратил время на прогон buildreq ради частичных BR; - ты потратил время на выкидывание "лишней" зависимости; - я потратил время на добавление её назад в другом месте. Итоговый результат -- суммарные сборочные зависимости в лучшем случае сохранились без изменений, зато потрачена стопка твоего и сколько-то моего времени. На что? > Если бы тестовая пересборка была частью сборочной системы, > то анализировать эту информацию было бы проще. Может, откатим этот набор улучшений до той поры? > > > Создавать бранч в ближайшее время не рекомендуется. > > Если исправлять молча в одностороннем порядке, то и > > к осени можно не управиться с разгребанием последствий. > Проще ничего не делать и в час X объявить сизиф стабильным. > Вследствие крайней нужды в стабильном бранче. Это другая крайность. :) -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/