From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 6 Feb 2012 13:38:12 +0400 From: "George V. Kouryachy" To: ALT Linux Team development discussions Message-ID: <20120206093812.GB20344@imap.altlinux.org> Mail-Followup-To: ALT Linux Team development discussions References: <20111221122555.GA32287@mail.truecrux.org> <4EF1D833.7030304@altlinux.org> <20111221183730.GA24356@dad.imath.kiev.ua> <4EF301D0.6060609@altlinux.org> <20111222205611.GA16904@dad.imath.kiev.ua> <11aca36c3406b4e751293dfd65270a50@office.etersoft.ru> <20120128001938.GA15519@altlinux.org> <20120201174747.GA4025@altlinux.org> <20120201185758.GA9858@altlinux.org> <20120202003649.GA15652@altlinux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120202003649.GA15652@altlinux.org> User-Agent: Mutt/1.4.2.3i Subject: Re: [devel] Q: personal package repositories: user PoV 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: Mon, 06 Feb 2012 09:38:12 -0000 Archived-At: List-Archive: List-Post: On Thu, Feb 02, 2012 at 04:36:49AM +0400, Alexey Tourbin wrote: > Упорядочить по BUILDTIME само по себе никакого смысла нету, можно только > упорядочить (умозрительно) по ингредиентам C, так что пакет, собранный > в чруте С1 с новыми версиями, должен быть "немножко больше" пакета, > собранного в среде C0 со старыми версиями. Это частичный порядок, > и BUILDTIME плохо его аппроксимирует. Возможно, существуют условия, внутри которых постоянно увеличивающийся счётчик всё-таки имеет смысл. Например, для репозитория на git.alt в рамках одного подновляемого разделяемого задания NSVR+такой счётчик дадут картину не хуже, чем просто NSVR. А вот когда репозиториев _несколько_ -- возможны неприятности. Но, например, если NSVR в этих репозиториях различаются, проблем опять не должно быть. Возможно, при сборке в карман надо один раз увеличивать релиз, а затем использовать какой-то счётчик типа BUILDTIME. Или как-то ранжировать сами репозитории, чтобы при совпадении NSVR выигрывал всегда один из них, не взирая на BUILDTIME. > Вообще, для чего всё это нужно? Кто-то установил предварительную сборку, > а сборочная система потом ещё раз пересобрала пакет, и он автоматически > уже не обновится. Ну в принципе это достаточно частная проблема, На самом деле не такая уж и частная. Это проблема тестирования сборок, которй у нас нет именно потому, что нет тестовых репозитариев. И в этом смысле возникает ещё один кусок workflow, который непонятно как зашить в банальное расширение NSVR: человек подключает тестовый репозиторий, обновляется из него, ничего не работает, он отключает тестовый репозиторий, и... дальше что? В идеале хотелсь бы снова обновиться, и всё. То есть, чтобы при наличии репозиториев A и B побеждали бы пакеты из B, а при одном только A -- пакеты из A. > Если он достаточно хитрый из армян, то > cd /ALT/Sisyphus/files/x86_64/RPMS && rpm -Fv perl-*.rpm Нет-нет, не только. Для начала нужно rsync с git.alt (речь ведь идёт о расширении возможностей сборочницы, в локальной сборке можно что угодно намутить и так). Заметим, rsync по timestamp в качестве последнего сравнения. Затем rpm -F, но не на всех пакетах их rsync-нутого репозтория (а то вдруг их там стопятьсот), а на свежеобновлённых (опять-таки вычисляемых по timestamp, если всё остальное внезапно совпадает). Ergo, в этой процедуре _тоже_ участвует инкрементальный счётчик. Если не BUILDTIME, то номер сборочной итерации в данном задании. -- George V. Kouryachy (aka Fr. Br. George) Mailto/JID: george@altlinux.org Mobile: (8)9161738325