Как лучше установить wine32 на 64-битной системе?

В контейнер.

Еще есть winepak и com.usebottles, но это пионерские поделки. Если вопрос безопасности не на первом плане, то можно попробовать.

Контейнер, да. Если у тебя не Nvidia, то можешь мой проект попробовать.

chmod +x conty_lite.sh
./conty_lite.sh wine something.exe

Это готовый к использованию контейнер со всеми зависимостями внутри, соответственно multilib в системе не нужен.

И тебе, скорее всего, придется unprivileged_userns_clone включить, раз у тебя Debian.

# sysctl kernel.unprivileged_userns_clone=1

Чем же стандартный подман не угодил?

Я не изучал podman. Его можно в обособленный исполняемый файл запихнуть? Судя по описанию, это немного разные вещи. Conty - из коробки готовое к использованию решение, в систему ничего устанавливать не нужно (кроме разве что fuse2, если не установлен), настраивать тоже ничего не нужно.

Можно, конечно, при желании образ контейнера запихнуть в скрипт, его запускающий (как у вас), но это дикое извращение. Образ контейнера нужно считать новым типом «исполняемого файла», контейнер – новым типом «процесса», изолируемого и управляемого стандартным образом.

Нет там никакого dependency hell, ставь multiarch, он аккуратный и беспроблемный.

Вот когда система 32-битная а надо запустить wine64 - другое дело, там без chroot наверно не обойтись.

Если же mutliarch ни в коем случае не хочется, то есть два варианта, оба не очень удобные (по сравнению с штатной установкой).

1. собери набор всех нужных ему .so (32-битных), закинь в специальное место, и запускай wine с настройкой брать библиотеки оттуда (настройку можно сделать либо через LD_LIBRARY_PATH, либо через патченый /lib/ld-linux, впрочем я ни то ни то с wine не пробовал)
2. chroot и аналоги, в том числе контейнеры, по сути это всё одно и то же, только с разной степенью изоляции процессов для безопасности (гайд простой: ставишь 32-битную систему через debootstrap, потом chroot в неё и дальше работаешь как на хосте)

У первого варианта (и у штатной установки) есть огромный плюс - wine запускается в контексте рабочей системы и сразу имеет доступ ко всему что может понадобиться (например документы в homedir).

Если это не нужно, или тем более нежелательно - chroot и прочие контейнеры, но шарить данные (а то и что-то ещё) между основной системой и контейнером придётся вручную.

Для chroot ещё надо будет пробросить X11 туда (делается копированием при каждом запуске файла ~/.Xauthority и переменной $DISPLAY).

Нет там никакого dependency hell

Ну вот сегодня запускаю apt update и получаю прилетевшее поломанное обновление (как я понял, Дебиан накосячил и не протестил как следует):

The following packages have been kept back:
  libgnutls30

Лезу в Синаптик и пробую обновить пакет -> он хочет снести мой wine32.

Спасибо. Помню, когда-то уже пробовал, но он все равно не запускался. Попробую еще раз...

В контейнер

Подскажи, плиз, как правильно. Кинь гайдом, ибо ваще ноль.

Есть еще Wine Appimage, можешь его попробовать.

С Wine первый вариант не получится без использования специальных хуков через LD_PRELOAD.

Заработал conty_lite! Спасибо, потестим.

Лезу в Синаптик и пробую обновить пакет -> он хочет снести мой wine32.

Это нормальное поведение дебиана и вайн тут ни при чём.

А кто вообще говорит, что вайн тут при чем?

Никогда не пользовался синаптиком.

Во-первых, apt update (может upgrade?) обновляет только незначительные изменения, для обновления всего надо apt-get dist-upgrade.

Во-вторых, можно попробовать написать apt-get install libgnutls30 wine32 и посмотреть что он предложит.

В-третьих можно чуть подождать, может там в процессе обновления репозиторий.

Почему это?

в бинарнике wine патчим путь к ld-linux с /lib/ld-linux.so на /zzz/ld-linux.so В /zzz/ld-linux.so кладём патченый загрузчик, который ищет библиотеки в другом месте.

К сожалению, с Wine так не работает. Здесь есть обсуждение на эту тему.

upgrade

Неважно. Меня поняли, если что.

обновляет только незначительные изменения

Все он обновляет как надо. dist-upgrade выдает то же самое, если что.

apt-get install libgnutls30 wine32

The following packages have unmet dependencies:
 wine32:i386 : Depends: libwine:i386 (= 4.0-2) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

Ты ожидал увидеть что-то другое?

в процессе обновления репозиторий

А вот здесь мы с тобой правы. Выше я написал, что, скорее всего, разрабы не протестили толком и вылез dep hell. Об чем и речь в посте.

Отдельный 32-битный wine prefix.

export WINEPREFIX=~/wineprefixes/wine32/
export WINEARCH=win32
wineboot

Сам wine взять тот который предлагает дистрибутив.

Как ты представляешь себе запуск 32-битной приложухи на 64-битной системе?

wineboot
it looks like wine32 is missing, you should install it.
multiarch needs to be enabled first.  as root, please
execute "dpkg --add-architecture i386 && apt-get update &&
apt-get install wine32"

Я ж написал «без мультирача в системе».

Тогда только виртуалка либо чрут с 32битными зависимостями (что равносильно установки зависимостей в системе), потому что 32битные виндовые аппликухи не заработают. Не понимаю этого дрочева с «без мультирача», жалко места на диске?

Там про другое. Запускать лоадер вручную (разумеется, он тогда будет действовать только на этот бинарник а не на его детей) я не предлагал.

Я предлагал пропатчить сам бинарник: в нём прописан путь к ld-linux (набери less /bin/sh и увидишь на первой странице), на другой путь, главное чтобы длина строки совпала. Например, создаём в корне /w32/ и заменяем во всех бинарниках в строке /lib/ld-linux.so.2 lib на w32. После чего запускаем их как обычно, они будут использовать наш лоадер. В лоадере уже прописываем любую логику, какую пожелаем, чтобы всё грузилось откуда надо.

Придумал кстати более менее простой способ всё это обновлять: поскольку патчить надо только запускаемые бинарники (.so не надо), то можно установить всё в chroot, в патченом /w32/ld-linux.so сделать чтобы он искал библиотеки в этом chroot-е, ну а сами wine, wineserver и что там ещё после обновлений перекладывать наружу, патча в них путь к лоадеру.

Не понимаю этого дрочева с «без мультирача»

Потому что вот это. Мне-то не жаль места. Не хочу просто срать в систему 32-либами.

В принципе, проблему я решил. Точнее решил ее Kron4ek портативным вайном, за что ему отдельное спасибо.

Да, ты прав, что-то я тупанул, замена пути к ld-linux в бинарниках действительно должна работать.

Вопрос: а как-то можно эту сборку урезать чисто до самого минимума? Чтобы не 1.2 гига :) Или это и есть самый минимум?

Я над этим тоже думал и понял что такой wine это засада и полное диверсити и тянет лишнее особенно задело что тянет библиотеки mesa i386 как будто не может через x86_64 ретранслировать приходиться мериться , но современные системы в отличии от 16.04 заставляет тормозить ui , а убераешь нафиг эти все i386 так ничего не тормозит , но по лёгкости все равно хуже чем спец система 16.04 , далее развите она не получила по причине дол..ма сообства , а ее можно было поднимать и поднимать нужно было финансирование уровня базальт

Это не самый минимум, там же еще Steam, Lutris и прочие программы внутри, а самый минимум с Wine - это где-то 700-800 MB. Готовую сборку никак не урезать, но можно сделать свою с любым набором пакетов, скрипты у меня в репозитории есть.

Это все-таки контейнер, так что да, размер относительно большой, тут ничего не поделаешь. И это он еще сжатый, в несжатом виде он около 4 GB весит.

Вот сборка только с Wine внутри.

Уфф, mega.nz, которая тащит все в кеш браузера сначала... Сурово. Но спасибо большое. А на Дебе я соберу его твоим скриптом или нужен Арч?

А на Дебе я соберу его твоим скриптом или нужен Арч?

На любых дистрибутивах должно работать. Но если будут какие-то проблемы, напиши, я постараюсь помочь.