From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ya.ru; s=mail; t=1707053336; bh=21gQobnrQ5Baw3nP7ipNhkir0s71XhlF8D+vg4ypdCE=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=MlpXvSk181u7yM+gvhNyDEiDH041b20OYFf6GSE8rgkFeSJzIsi+wds+sSztiUkn2 3HHtRAnN6JwdFX70pZuvKLdXWKmMt4ea8bP6+uM64J/v19Vkge2OTDPk/PS0k2hP4d dLxhEsh3JS+YXGYePzdpLtYvPuqczzJhQOF4ZxAc= Authentication-Results: mail-nwsmtp-smtp-production-main-84.iva.yp-c.yandex.net; dkim=pass header.i=@ya.ru Message-ID: Date: Sun, 4 Feb 2024 20:28:55 +0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: ru To: devel@lists.altlinux.org References: <861ed455-6004-428d-8615-404926d866a6@basealt.ru> <0450c7c7-24ba-4b70-bd46-c758f17dfb24@basealt.ru> <153f116e-5016-4201-ac63-40902891c7a3@ya.ru> <6ac6104e-ce0a-4148-bf73-308173d8f7fc@ya.ru> From: =?UTF-8?B?0JDQvdGC0L7QvSDQnNC40LTRjtC60L7Qsg==?= In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [devel] possible incompatibilities 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: Sun, 04 Feb 2024 13:28:59 -0000 Archived-At: List-Archive: List-Post: 04.02.2024 19:20, Arseny Maslennikov пишет: > On Sun, Feb 04, 2024 at 05:45:23PM +0700, Антон Мидюков wrote: >> 04.02.2024 17:30, Arseny Maslennikov пишет: >>> On Sun, Feb 04, 2024 at 02:46:44PM +0700, Антон Мидюков wrote: >>>> Почему самостоятельный переезд пакетов в /usr/ может сломать в будущем переезд на usr-merge? >>> >>> Тут надо прояснить смыслы слов. >>> >>> Я так понял, что переезд — это наивный перенос; взять и упаковать в >>> другое место, из старого убрать. Такой наивный перенос файлов ломает не >>> будущее, а обновление с прошлого. >> >> Да, я про такой перенос. Но перенос уже после того, как filesystem в репозитории обновлён. >> Разумеется, я не про то, чтобы собирать в p10 такие пакеты. А только в p11 и Сизиф. >> >>> >>> Вот гипотетический пример: если в соотв. пакетах, например, coreutils >>> или util-linux, просто взять и убрать все файлы вне префикса, >>> перенеся, например, /sbin/mount в /usr/sbin/mount, то: >>> - на системах со split-usr при загрузке до появления /usr файл >>> /bin/mount будет отсутствовать; >> >> При обновления /usr уже примонтирован. >> >>> - такой пакет перестанет удовлетворять Requires: /sbin/mount. >> >> Так он не соберётся в репозиторий, если не будет удовлетворять зависимостям. > > Вот именно. Для ряда пакетов такие зависимости существуют, то есть их > файлы сейчас просто нельзя наивно переложить и собрать в репозиторий; > нужно формировать пакет так, чтобы он ставился на все иерархии, хотя бы > для того, чтобы он смог установиться в хешерницу на сборочнице, где > собирают другие пакеты. > Есть такой милый, бесполезный пакет lsb-core, который из таких > зависимостей в существенной степени и состоит. > > Более того, в пакетах бывают post-скрипты; они пользуются программами > из /bin и /sbin, а те — библиотеками из /%_lib. Если на момент запуска > post-скрипта иерархия ещё не переведена, а пакет с программой уже > обновился и перенёс файл под префикс, то по старому пути он будет > недоступен; если его запускают без учёта PATH — процесс оборвётся. > >>> Или, если речь идёт о sh и awk каких-нибудь, они часто указаны в >>> сценариях в качестве интерпретаторов: "#!/bin/awk". Файл по этому пути >>> должен быть. >> >> Так после обновления всё уже будет. >> >> Я не понимаю, почему мы не можем сразу же после обновления filesystem начать перенос в спеках в /usr по мере обновления пакетов, которые не планируется собирать в p10. >> Почему мы должны ждать p12? > > Потому что тогда filesystem должен будет обновиться строго до того, как > эти пакеты установятся в систему, т. е. надо будет мимо rpm переносить > файлы под префикс в том виде, в котором они будут в старой системе (p10 > или Sisyphus от древней даты). То есть при обновлении с бранча p10 до p11 установка filesystem перед dist-upgrade должно решить проблему? Если так, то это можно прописать в инструкции обновления p10 -> p11. > > В случае, если мы это делаем до обновления или перед распаковкой нового > filesystem, у нас нет способа доказать, что это возможно автоматически > сделать для ∀ возможных множеств установленных пакетов. Я задумываюсь > над тем, чтобы, если обнаруживаются неисправимые конфликты, не > игнорировать их, как сейчас, а завершаться со статусом != 0, и запускать > это в %pretrans; тогда, по идее, апгрейд тоже завершится с ошибкой до > того, как будут затронуты какие-то файлы. > (Неисправимый конфликт — это, например, /bin/ex -> vi и /usr/bin/ex -> > vim; не очевидно, какой из них стоит оставить, а какой убрать. Тут нужно > менять пакет vim. А при обновлении надо будет сначала поставить > исправленную версию, а потом повторять апгрейд.) > >> почему мы не можем... начать перенос в спеках. >> почему мы должны ждать p12? > Если коротко, то: > * если получится совершать миграцию в posttrans — можем; > * если мигрировать в pretrans и заранее отказываться трогать что-либо > при неисправимых конфликтах — тоже можем; > иначе лучше не надо. > > > _______________________________________________ > Devel mailing list > Devel@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/devel -- С уважением, Антон Мидюков