[devel] Использования зеркал хранилищ пакетов

[Rx]

Привет!

06.2026 20:59, Vladimir Romanov пишет:
>
> Всем привет. Прочитал новость про зеркала всяческих пакетных сайтов от 
> gitverse (https://gitverse.ru/docs/artifactory/registry-mirrors/): 
> Docker Hub, Maven Central, NPM, PyPI, Go Proxy, Crates.
>
> Хотел бы вынести на обсуждение, может стоит ли оверрайдить провайдеров 
> в пакетах python3(pip), cargo, go и т.д.? 

Есть пара вопросов:

 1. Какую проблему это решает? Чем это отличается от подключения напрямую?
 2. На ком лежит отвественность за сопровождение зеркала? Кого винить в
    случае, если зеркало будет содержать скомпрометированные зависимости?
 3. Предоставляет ли подобный механизм возможность исправления
    определённых зависимостей в случае обнаружения уязвимостей или
    проблем архитектуры не учитывающих особенностей дистрибутива?
 4. По какому принципу зависимости должны попадать/попадают в зеркало?
    Например для Rust некоторые зависимости могут располагаться вне
    crates.io
    <https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-other-registries>,
    соотвественно зеркало для crates.io не решает проблему полностью.

На мой взгляд у вендоринга (по опыту сопровождения Rust пакетов) 
следующие проблемы:

 1. Раздувание srpm и gear. Многие пакеты дублируют одни и те же
    зависимости; многие пакеты, даже самые простые, могут содержать под
    300 зависимостей, что в сумме может на порядок превышать размер
    исходников собираемого пакета.
 2. Отсутсвие механизма исправления зависимости для всех пакетов которые
    её используют. В случае если зависимость получает исправление
    безопасности или критической ошибки, попадание исправления в пакет
    зависит напрямую от заинтересованности мейнтейнера копаться во всех
    зависимостях.

Автоматизация загрузки зависимостей/вендоринга на мой взгляд не является 
проблемой (по крайней мере для Rust), так как уже существует как минимум 
4 различных решения этой проблемы, со своими плюсами и минусами.

Решением обеих проблем является перенос зависимостей в собственное общее 
пространство:

Либо пространство пакетов, например через сборку noarch пакетов (подход 
Fedora для Rust 
<https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/>), либо 
пространство собственных зеркал.

Первый подход плох тем, что для него нужно создавать систему 
автоматизации, потому что непонятно у кого есть свободное время на 
упаковку 20000+ пакетов со всеми флагами и фичами, и засорением 
репозитория пакетами, которые непредставляют почти никакой пользы для 
пользователя.

Второй требует разработку новой инфраструктуры и правил эксплутации .

> Если с питоном можно просто ставить необходимые модули из репозитория, 
> то с go/rust/npm всё сложнее.
Для Rust можно адаптировать подход из Fedora. Если не ошибаюсь там есть 
политики и для других языков.
----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20260622/eb0be1f0/attachment.html>