From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 24 Mar 2011 03:36:51 +0300 From: Alexey Tourbin To: ALT Linux Team development discussions Message-ID: <20110324003651.GK30247@altlinux.org> References: <20110323231713.GU9385@osdn.org.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110323231713.GU9385@osdn.org.ua> Subject: Re: [devel] =?koi8-r?b?0NLB18nM2M7ZxSDawdfJ08nNz9PUyQ==?= 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: Thu, 24 Mar 2011 00:36:52 -0000 Archived-At: List-Archive: List-Post: On Thu, Mar 24, 2011 at 01:17:13AM +0200, Michael Shigorin wrote: > On Thu, Mar 24, 2011 at 01:03:28AM +0300, Alexey Tourbin wrote: > > > > Если рациональные аргументы не интересуют > > Сделай мне лично одолжение -- прочти вот эту статью: > http://egorfine.com/ru/articles/worse-than-failure/ Прочитал. Там написано, что надо признавать свои ошибки. Исправление зависимостей у *-devel пакетов ошибкой не является. В техническом отношении, по крайней мере. > > > Так их и не видно пока. Вещание в одни ворота. > > Рациональный аргумент у меня почти один - у пакетов должны быть > > правильные зависимости. > > Определи правильные зависимости, пожалуйста. Не докапываюсь, > просто когда подходит к трактовке слов, лучше сразу уточнить. Правильные зависимости - это все те и только те зависимости, которые обеспечивают работоспособность пакета, что обычно означает возможность использовать по прямому назначению его содержимое. Факторы работоспособности *-devel пакетов: 1) Возможность включать хедеры (т.е. должны быть зависимости на хедеры, которые включаются в свою очередь). 2) Возможность вызывать pkg-config (т.е. должны быть зависимости, которые обеспечивают Requires в *.pc файлах, иначе pkg-config откажется давать результат). 3) Возможность линковки. Если в .pc:Libs: указаны дополнительные библиотеки, то они должны быть поддержаны соответствующими зависимостями. Впрочем, настоящая необходимость указывать дополнительные библиотеки в Libs: возникает очень редко - дополнительные библиотеки в Libs: чаще всего находятся по ошибке, тогда как на самом деле им место в Libs.private. Все зависимости, которые не являются правильными, являются неправильными. > > Если от исправления зависимостей ломаются другие пакеты, то у > > других пакетов тоже неправильные зависимости, и они тоже должны > > быть исправлены. > > Смотри, это можно сделать двояко. Либо разгребя дорогу перед > теми, кто может добраться и помочь -- либо распинав их со своей > дороги и... и тогда своими руками. > > Мне кажется, что _правильным_ способом реализации той расчистки, > что ты задумал и начал делать не с того конца -- был бы такой: > > 1) анонс задумки в devel@; > 2) модификация buildreq для исключения случайных потерю полных BR; > 3) анализ сизифа на предмет предположительно лишних зависимостей; > 4) обсуждение полученного списка удалений по части особых случаев > ("так задумано для...") и документирование их в спеках; > 5) прогон buildreq -u по затрагивающимся пакетам (хорошо бы > заодно и версии/spec cleanup/патчи в апстрим...); > 6) когда хотя бы большая часть (пусть 80%) затронутых пакетов > получили зафиксированные полные сборочные зависимости, > можно вырезать лишние из графа; > 7) потихоньку фиксить остатки, имея под рукой (на вики, > здесь, лишь бы где-то был) текущий список оставшегося; > 8) когда пыль начнёт оседать, можно открутить дефолт для > buildreq назад к оптимизирующему (хотя IMHO хранить полный > список в закомментированном виде весьма полезно); > 9) и хорошо бы подвести итоги -- что было, что стало, > чего добились и что по дороге оказалось иначе. > > Такой подход куда более нудный, чем с шашкой в бой, но скажи, > в каких пунктах неправ и было бы предсказуемо хуже? Или тебе > просто такое неприемлемо? Это всё долго и глупо. По сути, надо сделать две вещи. Сначала исправить *-devel пакеты. Потом исправить пакеты, которые из-за этого сломались. Пакеты, которые явно сломались, видно в beehive_status. Исправить их не очень сложно. Некоторые пакеты стали собираться в урезанной конфигурации. Такие пакеты сложнее идентифицировать. Виновата в этом фирма альт линукс, а вовсе даже не Алексей Турбин, т.к. его идея интеграции тестовой пересборки в сборочную систему и создания метарепозитория материально-технически поддержана не была (хотя разговоров об этом было много). Лучшее, что у нас сейчас есть - это сравнение пакетов, которое в beehive после тестовой пересборки. Кстати это сравнение там не само вскочило - его кто-то закодил. Кажется, именно этот код теперь называют rpmdiff. > > Сохранине статуса-кво перед созданием нового бранча могло бы > > иметь некоторой смыл, хотя к рациональным аргументам это не > > отнсится. > > Rationale: стабилизировать реальней то, от чего знаешь, > чего ожидать (проверено собственноручно на 4.0/branch > и Terminal 4.0 -- по качеству он, похоже, вышел почти > как Master 2.4, если судить по отзывам). > > Contra: сделать вагон бинарно несовместимых изменений сразу после > бранча -- значит в который раз напороться на повышенные обяза^W > в смысле кровопотери по техническому бэкпортированию. > > В любом случае очень надеюсь, что бранч не свалится как снег > на голову.