[devel] Q: personal package repositories: user PoV

[Michael Shigorin]

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 <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/