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=-1.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_WEB,SPF_PASS autolearn=no version=3.2.5 Date: Sat, 26 Nov 2011 12:58:46 +0200 From: Igor Vlasenko To: devel@lists.altlinux.org Message-ID: <20111126105846.GA15128@dad.imath.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.21 (2010-09-15) X-imath-kiev-ua-MailScanner-Information: Please contact the ISP for more information X-imath-kiev-ua-MailScanner-ID: 6D6D64B010E.ABD4E X-imath-kiev-ua-MailScanner: Found to be clean X-imath-kiev-ua-MailScanner-From: vlasenko@imath.kiev.ua Cc: ldv@altlinux.org Subject: [devel] =?utf-8?b?0KDQsNGB0L/QsNGA0LDQu9C70LXQu9C40LLQsNC90Lg=?= =?utf-8?b?0LUgaW5jb21pbmcu?= 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: Sat, 26 Nov 2011 10:58:55 -0000 Archived-At: List-Archive: List-Post: Несколько в сторону, по поводу incoming. DVL> Если кому-то нужно устроить continuous integration для каких-то проектов, DVL> то [...] сборочница вряд ли справится с такой нагрузкой. Как я понимаю, наша сборочница устроена так, что если по окончанию сборки пакета его сборочное окружение успело измениться, пакет посылается на сборку еще раз. Это означает, что увеличение числа параллельных потоков сборки может даже замедлить incoming, так как потоки вместо сборки новых пакетов будут заниматься постоянной пересборкой старых. Это поведение является защитой от появления unmets. Но надо понимать, что это достаточная защита, но, на самом деле, не необходимая. Для многих пакетов, те же moodle*-lang-* пакеты, к примеру, такое поведение не нужно. Для таких пакетов заведомо ничего страшного не случится, если они будут собраны на позавчерашнем сизифе, проверены на устанавливаемость на вчерашнем сизифе, включены в сегодняшний сизиф. Почему так? Трюк здесь в том, что у этих пакетов зависимости новой версии и старой версии не отличаются. Поэтому для такого класса пакетов сборку можно оптимизировать. Если мы собрали пакет, и оказалось, что - его requires зависимости не изменились, то 1) пересобирать такой пакет уже не нужно, пусть Сизиф себе обновляется, тесты останутся релевантными. 2) если при этом на provides такого пакета нет жесткой зависимости, вида = или =set: то такой пакет обладает свойством, что он не мешает сборке других пакетов. Т.е. если во время сборки другого пакета B в Сизифе обновился пакет C из сборочного окружения В, и у этого С зависимости инвариантны, то при сборке и тестировании В на обновление пакета С можно не обращать внимания. Unmets не будет. Другими словами, часто можно разрешить, чтобы в процессе прохождения пакета Сизиф мог меняться, при этом сборка таких пакетов не блокирует Сизиф и замечательно распараллеливается. имело бы смысл сборочнице распознавать такие пакеты. -- Dr. Igor Vlasenko -------------------- Topology Department Institute of Math Kiev, Ukraine -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.