---

Теперь причина ясна. В вашей ALT p11 установлен `eepm 3.64.35`, а пакет OpenCode после перепаковки получает ложную зависимость:

```text
libc.so()(64bit)
```

Это **не нормальная зависимость glibc** для ALT. У вас glibc, конечно, установлен — без него сама система не работала бы. Проблема в генерации метаданных RPM при перепаковке.

В более новых `eepm` механизм обработки библиотечных зависимостей менялся: появились отдельные исправления фильтрации `.so`-зависимостей; текущий Sisyphus уже содержит значительно более новый `eepm` 3.64.66, тогда как у вас 3.64.35. ([GitHub][1])

### Я бы сейчас выбрал AppImage

Для **OpenCode Desktop на ALT p11 это самый чистый вариант**: не нужно ломать RPM-зависимости и вмешиваться в пакетную базу. Сам OpenCode официально выпускает Desktop для Linux в `.deb`, `.rpm` **и `.AppImage`**. ([GitHub][2])

Скачайте файл вида:

```text
opencode-desktop-linux-amd64.AppImage
```

и установите его в домашний каталог:

```bash
mkdir -p ~/.local/opt/opencode

mv ~/Загрузки/opencode-desktop-linux-amd64.AppImage \
   ~/.local/opt/opencode/opencode-desktop.AppImage

chmod +x ~/.local/opt/opencode/opencode-desktop.AppImage
```

Запуск:

```bash
~/.local/opt/opencode/opencode-desktop.AppImage
```

Если запускается — вопрос решён без `rpm`, `apt-get` и `eepm`.

---

### Если AppImage пожалуется на FUSE

Можно вообще не использовать FUSE, а распаковать AppImage:

```bash
cd ~/.local/opt/opencode

./opencode-desktop.AppImage --appimage-extract
```

Появится каталог:

```text
squashfs-root
```

Переименуем:

```bash
mv squashfs-root AppDir
```

И запускаем:

```bash
~/.local/opt/opencode/AppDir/AppRun
```

Такой способ часто удобнее именно на дистрибутивах, для которых приложение официально не собиралось.

---

### А что с вашим RPM?

Для начала можете подтвердить, что зависимость действительно искусственная:

```bash
rpm -q --whatprovides 'libc.so()(64bit)'
```

С большой вероятностью получите, что поставщика нет.

А вот реальная glibc:

```bash
rpm -q glibc-core
```

и:

```bash
ldd --version
```

ALT p11 действительно содержит glibc. ([Alt Linux Packages][3])

Поэтому **устанавливать какую-то дополнительную `libc` не надо**. Особенно не нужно искать сторонний RPM с `libc.so`: можно повредить систему.

### Можно ли просто сделать `rpm -Uvh --nodeps`?

Технически:

```bash
sudo rpm -Uvh --nodeps \
  /var/tmp/tmp.4RAxLIF7z5/opencode-1.18.16-epm1.repacked.2.x86_64.rpm
```

может сработать.

Но я пока **не рекомендую** это делать, потому что сначала стоит выяснить, является ли `libc.so()` только ошибочной RPM-зависимостью или какой-то файл внутри OpenCode действительно слинкован с `libc.so` вместо `libc.so.6`.

Это можно проверить без установки.

Для исходного RPM выполните:

```bash
rpm -qpl ./opencode-desktop*.rpm
```

И отдельно очень полезно:

```bash
rpm -qp --requires ./opencode-desktop*.rpm | grep libc
```

А для перепакованного:

```bash
rpm -qp --requires \
  /var/tmp/tmp.4RAxLIF7z5/opencode-1.18.16-epm1.repacked.2.x86_64.rpm | grep libc
```

Если у **исходного** RPM нет

```text
libc.so()(64bit)
```

а у перепакованного он появился — тогда это практически однозначно ошибка старого `eepm`.

### Обновление eepm — второй вариант

Ваш корпоративный репозиторий зафиксировал:

```text
eepm 3.64.35-alt1
http://nexus.mycompany.ru ... p11/date/2025/12/07/
```

То есть обычное:

```bash
sudo apt-get update
sudo apt-get install eepm
```

вам новую версию не даст.

При этом upstream Etersoft официально предлагает установку свежего EPM своим скриптом:

```bash
curl -sL https://eepm.ru/epm.sh | sudo bash /dev/stdin ei
```

и также публикует пакеты EPM через свой Korinf. ([GitHub][4])

**Но в вашем случае я бы этого пока не делал.** Судя по `nexus.mycompany.ru`, у вас корпоративное зеркало/фиксированный snapshot. Подмена системного `eepm` внешней версией может противоречить принятой схеме обновлений.

И тем более **не надо подключать Sisyphus к p11** только ради нового `eepm`.

### Поэтому мой порядок действий

1. **OpenCode CLI** — ставить официальным tar/install-скриптом.
2. **OpenCode Desktop** — использовать `AppImage`.
3. RPM оставить в покое, пока не проверим, откуда возник `libc.so()(64bit)`.
4. Не использовать `--nodeps`, пока не проверим ELF-зависимости.

Пришлите вывод всего **двух команд**:

```bash
rpm -qp --requires ./opencode-desktop*.rpm | grep -E 'libc|libgcc|libstdc'
```

и

```bash
rpm -qp --requires \
/var/tmp/tmp.4RAxLIF7z5/opencode-1.18.16-epm1.repacked.2.x86_64.rpm \
| grep -E 'libc|libgcc|libstdc'
```

По сравнению этих двух выводов я смогу сказать, можно ли безопасно **вырезать только `libc.so()(64bit)` из RPM и собрать нормальный ALT-пакет**, не используя `--nodeps`.

[1]: https://github.com/Etersoft/eepm/blob/master/eepm.spec?utm_source=chatgpt.com "eepm/eepm.spec at master · Etersoft/eepm"
[2]: https://github.com/anomalyco/opencode?utm_source=chatgpt.com "anomalyco/opencode: The open source coding agent."
[3]: https://packages.altlinux.org/en/p11/srpms/glibc/?utm_source=chatgpt.com "p11 - glibc-2.38.0.123.650a0-alt1 - The GNU libc libraries"
[4]: https://github.com/Etersoft/eepm/?utm_source=chatgpt.com "Etersoft EPM package manager"