Возрождение debian-cosy

[vitus_wagner]

Тут решил восстановить свой собственный репозиторий пакетов дял Debian, Который мы когда-то создали вместое с filin еще в самом начале века, а потом лет десять назад я его забросил.

Просто у кого-то слишком много ноутбуков и поэтому удобнее собрать что-то нестанрдартное в пакет, чтобы ставить на все компы. Особенно если его еще и обновлять приходится.

Ну а раз пакет собрал, почему бы его не выложить для всех желающих. В общем, см https://www.wagner.pp.ru/debian.

Настроил себе sbuild под три дистрибутива. Попробовал пересобрать xephem для arm64 в режиме кросс-компиляции. Собралось.

А вот сбэкпорить telegram-desktop из testing не получилось. В режиме кроссборки что-то не то вышло с build-dependencies - sbuild не смог установить пакет архитектурой all для разрешения зависимости при кросс-сборке. А при нативной сборке в trixie налетаю на internal compiler error причем и на amd64, и на arm64. Но вообще сборка telegram-desktop на Raspbery Pi это еще то занятие. Даже с 8Гб.

Опять потоптался по любимым граблям что Debian устанавливает TMP=/tmp/user/$(id -u) и debootstrap с schroot это дело пробрасывают внутрь chroot. А /tmp-то там своя. И никто в ней эти поддиректории не создает. Плюнул и создал их вручную - для рута, юзера sbuild и всех членов группы sbuild (в которой пока один я).

Теперь бы еще надо скриптовую обертку вокруг sbuild и reprepro, чтобы пакет сразу попадал в локальную копию репозитория, и чтобы сразу пересобирало для всех поддерживаемых версий. А уж ее потом зарсинкаю на публичный сервер (исключив по дороге conf и db). Хотя, конечно, интересно выглядит синхронизцаия apt-mirror-ом по крону со стороны публичного сервера. apt-mirror хорош тем, что минимизирует время, в которое репозиторий невалиден.

Comments

[yurikhan]

В моё время™ у reprepro был фатальный недостаток: он держал единственную версию каждого пакета (под каждую архитектуру). То есть, выложил foo_1.1-1_amd64.deb, потерял foo_1.0-1_amd64.deb. Поэтому у нас было два репозитория, свежесобранный пакет клался в тестовый, тестировщики его ставили оттуда, проверяли, и пакет продвигался на боевой репозиторий только после их отмашки.

Ну это тоже лет десять назад было, а потом появился aptly.

[vitus_wagner]

Ну я не считаю это фатальным недостатком. Это особенность, которую надо учитьывать при организаации workflow, не более того. Мне пришлось поработать с дистрибутивом, у которого в репозитории одновременно лежат несколько версий одного и того же пакета (redos). Это - мрак.

Особенно когда ты пытаешься для такого дистрибудива собирать 3rd-party пакеты и распространять их.

Помнится у меня в PostgresProfessional была система архивирования репозиториев, в которой новая копия создавалась с каждым релизом продукта. Пятнадцать репозиториев в квартал. Естественно там была дедупликация через хардлинки. Но вся история того что могло попасть к пользователям - хранилась.

В принцие бы можно было использовать схему с множественгными Suites и миграцию из Unstable в testing, как это делают в самом Debian. Но для 3rd-party пакетов это неудобно. Suites должны соответсвовать версиям дистрибутива для которого делаешь пакеты.

А aptly конечно штука интересаная на предмет деланья снапшотов чужих репозиториев.

Снапшоты, кстати, сейчас в reprepro есть. В общем примерно такие же как делал я. Но у меня была своя надстройка, так как нужно было поддерживать не только debian и ubuntu, но и еще кучу rpm-based дистрибутивов.

[vitus_wagner]

Вообще интересная мысль - завести Suites testing-testing stable-testing и т.д. Тогда для каждой версии дистирибутива можно будет мигрировать пакет из suite для тестировщиков в suite для клиентов, и при этом пакет будет лежать в pool-е как лежал. Правда тогда публиковать stable-репозиторий придется чем-то типа apt-mirror. Чтобы лишнее наружу не уехало. pool-то общий. У снапшотов reprepro, впрочем, та же проблема - общий пул.

[yurikhan]

Ну общий пул — это не проблема, а особенность, которую надо учитывать при организации workflow :) Одно практическое последствие, которое я знаю — это что пакет с багом, выложенный в тестинг, нельзя починить и пересобрать с той же версией. Поэтому либо тестовые пакеты с хвостом ~таймштамп (и тестируется не совсем тот пакет, что публикуется), либо хотфиксы с инкрементом основной версии (и внутренние детали количества раундов тестирования либо номера билдов CI вытекают наружу).

[vitus_wagner]

Вообще-то можно пакет с багом, выложенный в репозиторий, поддерживаемый reprepro заменить на пакет такой же версии. У нас так делалось. Правда у нас там была весьма развеситая обертка над разными пакетными менеджерами. Тривиально - в два приема removesrc и include обратно уже другую сборку.

Это может порождать проблемы при установке, если кто-то не сделал apt update и у него пакет с тем же именем и версией оказался с другой хэш-суммой. Но тестировщиков можно приучить apt update делать.

Работает это, понятно, в той ситуации, когда пакет есть только в одном Suite. Но для тестируемого пакета это нормальная ситуация. Если же бага найдена в пакете который уже успели смигрировать в stable, то тут хочешь-не хочешь надо версию поднимать. А то вдруг кто из клиентов его уже поставил.

[vitus_wagner]

А вообще копирование внутреннерго репозитория в публичный не банальным rsync а софтом, понимающим структуру репозитория (что необходимо для того чтобы откопировать только часть suites, и соответственно только принадлежащие к ним пакеты из пула) имеет то дополнительное преимущество, что позволяет минимизировать время, в течение которого публичный репозиторий невалиден.

Поскольку можно сначала выложить новые пакеты, потом dists во временную директорию, потом ее переименовать в постоянную и только потом удалять ставшие ненужнгыми пакеты. Т.е. переключение со старого на новое состояние сводится к двум атоммарным rename.

 mv dists .dists.old
 mv .dists.new dists

После этого уже спокойно удаляется все что стало ненужным. Кто сделает apt update после этих двух mv, будет уже работать с новой версией.

[yurikhan]

А если dists делать не каталогом, а симлинком на каталог, то его можно переписывать новым симлинком на новый каталог вообще строго атомарно. Но это мы уже уходим с уровня «пользоваться инструментом» на «разрабатывать инструмент».

[vitus_wagner]

Интересно, почему так не делает тот же apt-mirror.

А грани между "пользоваться инструментом" и "разрабатывать инструмент" в общем-то и нет. Все равно инструмент надо какими-то скриптами оборачивать, интегрировать его с системой непрерываной интеграции и все такое.