Summary: | носит с собой и собирает zstd, несмотря на BR: libzstd-devel | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Michael Shigorin <mike> |
Component: | borg | Assignee: | Dmitriy Shadrinov <shadrinov> |
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
Severity: | minor | ||
Priority: | P5 | CC: | lav, shadrinov |
Version: | unstable | Keywords: | regression |
Hardware: | all | ||
OS: | Linux | ||
See Also: |
https://bugzilla.altlinux.org/show_bug.cgi?id=36408 https://bugzilla.altlinux.org/show_bug.cgi?id=41369 |
Description
Michael Shigorin
2022-04-24 22:29:34 MSK
Была ещё такая проблема: #41369. Я попробую оторвать. Меня беспокоит только такой момент: резервные копии - это такие штуки, которые в нормальной ситуации никому не нужны и о них вспоминают тогда, когда думать уже поздно, а стоит ли рисковать и залезать в кишки и ковырять своими руками? Если сборка проекта предусматривает использование внешней библиотеки, то вопросов нет. Что касается лично меня, я бы для себя предпочел использовать "нековыренный" код, либо надо реально полноценно знать код программы. Отправил сборку с системными liblz4, libzstd, libxxhash штатным способом (Ответ для Dmitriy Shadrinov на комментарий #1) > Если сборка проекта предусматривает использование внешней библиотеки, то > вопросов нет. Что касается лично меня, я бы для себя предпочел использовать > "нековыренный" код, либо надо реально полноценно знать код программы. Целиком понимаю и поддерживаю как админ; думаю, в таких случаях можно посмотреть, точная ли копия какой-либо версии запихнута в поставляемый архив, и если да -- спросить апстрим, из каких именно соображений (самодостаточность архива. нестабильность API/поведения, ещё что). А дальше уж с учётом этих вводных. Бездумно отрывать ради отрывания может вылезти боком как минимум в случае таскания _форков_ с неочевидными причинами вроде редких проблем... Сейчас поддержка системных версий библиотек реализована штатно без допиливания. |