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.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.5 Date: Sat, 4 Feb 2012 12:37:44 +0200 From: Michael Shigorin To: ALT Linux Team development discussions Message-ID: <20120204103744.GY31448@osdn.org.ua> 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.1i 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: Sat, 04 Feb 2012 10:37:50 -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 плохо его > аппроксимирует. Почему плохо-то? Для свежесобранных пакетов и базового репозитория в целом выполняется. > Вообще, для чего всё это нужно? Кто-то установил > предварительную сборку, а сборочная система потом ещё раз > пересобрала пакет, и он автоматически уже не обновится. > Ну в принципе это достаточно частная проблема, и этот кто-то - > обычно всего один человек. Для того, чтоб вместо достаточно частной проблемы можно было иметь достаточно общее решение (вспомни юзабельность дедала в плане "ой, забыл отключить"). > Если же он недостаточно хитрый из армян, то ему и не следовало > бы во всё это впутываться. Ага, а потом кто-нить будет жаловаться (и небезосновательно) на отсутствие денег. При подходе "и пусть они страдают" это вполне ожидаемо :( > Тебе хочется узаконить практику установки предварительных > сборок, чтобы реализовать "персональные репозитории". > А персональные репозитории - это новое слово из будущего, > которое манит нас своей загадочностью и неизвестностью. Вообще-то это то, что пока мы раскачивались -- уже сделали и вовсю применяют в Ubuntu и openSUSE. Только там писали скорее "в лоб" и вопросы управления получающимися форками, по отзывам пользователей, не особо продуманы (типичный случай вида "A есть в репо Ra, B есть в репо Rb, при попытке задействовать оба получаем конфликт по L"). Если приложить усилия к технической минимизации форка -- начиная с той самой возможности пересборки и последующего обновления по мере изменения той части базового репо, которая влияет на сборочную среду -- может получиться уже лучше, по крайней мере в части косвенных общих зависимостей. Да посмотри вон ченжлог collectd-5.0.x и подумай, а что если бы мне было важно сделать бесшовный переезд с автоматической миграцией данных, как ab@ старался делать для samba -- и тут библиотеки начинают сновать под ногами, как сговорившись? :) > Проблема промежуточных состояний в ней тоже возникает, когда > выполняется тестовая пересборка пакетов. В этой системе > различаются фактические сборки пакетов "A" и последующие > тестовые пересборки "T" в изменившейся среде. Соответственно, > система должна по-разному фиксировать "фактические" и > "фантомные" состояния. Именно, но в момент мержа кармана в базовый репо накопленные "фантомные" могут фиксироваться изменением "фактического" (гругря, release bump с соответствующей записью в changelog -- либо человеком, работающим над пакетом, либо скриптом, которому указана тема кармана -- "rebuilt with libZ.so.N"). > Но эта система была направлена на строгий учет изменений и > контроль целостности репозитория. А реализовать ее не удалось, > потому что это требовало сборочных ресурсов, которые оказались > фирме альт линукс не по карману. Ну сейчас-то сборочные ресурсы чуть расширились. И есть мысли насчёт того, как бы перетащить это всё на ещё более новый уровень (но пока практических результатов нет). > Так вот, видишь, новое слово из будущего - персональные > репозитории - мне не особенно понятно и близко. Во всяком > случае, эти идеи не растут из требований контроля целостности > и строгого учета изменений Почему? > в том числе после тестовой пересборки > (которая до сих по не выполняется). В смысле результат выбрасывается или ты о чём? -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/