Реквестирую скрипт для копирования бинарика вместе со всеми so-зависимостями

apt называется

exodus, но сам не пробовал.

На коленке с гуглом пополам

local appname = arg[1]
local appinfo = io.popen('apt info '..appname):read('*a')
local depends = appinfo:match('Depends: [%S+ (%S+),]+')

for package in depends:gmatch('%s[%w+-%d+%-]+%s') do
    os.execute('apt download '..package)
end

os.execute('apt download '..appname)
os.execute('mkdir -p approot')

for debfile in io.popen('ls'):lines() do
    if debfile:match('%.deb') then
       os.execute('dpkg-deb --fsys-tarfile '..debfile..' > '..debfile..'.tar')
    end
end

for tarfile in io.popen('ls'):lines() do
    if tarfile:match('%.tar') then
       os.execute('tar -xf '..tarfile..' -C approot')
    end
end

os.execute('rm ./*.deb')
os.execute('rm ./*.tar')

lua test.lua htop

В каталоге approot всё что надо htop вроде бы всё

apt называется

Тогда уж ещё и docker и/или debootstrap и/или chroot

и таки всё равно полезно + exodus :)

А это только один уровень зависимостей?

А со всеми уровнями получится копия выхлопа debootstrap ? :)

А это только один уровень зависимостей?

Ага, рекурсивный обход зависимостей уж допилит сам, потом можно как блоб собрать в 1 пакет через dpkg-deb -b approot mybigpackage.deb (вроде как-то так)

А со всеми уровнями получится копия выхлопа debootstrap ? :)

Ну, отчасти ты прав, но лишь отчасти, не будет например binutils со всем его ворохом сожержимого и кучи кучи ещё всего не будет если у пакета и всех его рекурсивных зависимостей нет от него зависимости. Но по сути это и есть аналог debootstrap, но всё же не он. Хотя, лень проверять вроде можно debootstrap сказать список пакетов которые нужно развернуть конкретно именно пакетов, но кажется он всё равно притащит в себя напрямую не зависящие вещи.

Нуачётыхотел все переплетено. Ты либо берёшь все зависимости и потом выкидываешь дубли что будут на системе на которую потащишь либо просто тащишь всё до чего дотянешься иначе или не запустится или упадёт на том или ином варианте использования.

Больше пути нет никакого или так или так.

Нуачётыхотел все переплетено. Ты либо берёшь все зависимости и потом выкидываешь дубли что будут на системе на которую потащишь либо просто тащишь всё до чего дотянешься иначе или не запустится или упадёт на том или ином варианте использования.

Проще chroot+debootstrap.

Больше пути нет никакого или так или так.

exodus же?

ldd

Софтина может делать dlopen и сама себе получать символы. Про такие зависимости тебе скажет только пакетный менеджер. А ещё софтина может через popen дёргать другую софтину о чём тоже скажет только ПМ, конечно можно на предмет этого сам бинарь «грепать», но зачем если всё о каждом пакете уже знает ПМ, спроси его что софтине надо и кочай (или спроси какие пути у файлов зависимостей и копируй с текущей системы)

Проще chroot+debootstrap.

Никто не спорит что проще, но аффтар не сказал как он будет запускать перенесённый софт, упаковывать в аппимагу, делать deb пакет, делать tar.gz с запуском из скрипта в котром указаны локальные пути или будет чрутаться в каталог, для первых варантов нет не проще будет, будет хлам который ещё придумать надо как вычистить, для последнего случая да, будет проще. Тут на финальную задачу нужно смотреть, он спрашивает как сделать, а не что ему надо. Последнего мы не знаем. Ну там ему виднее.

exodus же?

Второй раз про это слышу, первый раз в комментарии повыше было :D Может и действительно «же», а может и нет, варианты предложили, пускай пробудет.

А конфиги, постинсталл скрипты и прочие ресурсы кот собирать будет?

Если нужно делать это регулярно и для многих программ, то проще повеситься. Есть масса неочевидных нюансов, которые кажутся ерундовыми, но в реальности, без них не стартанёт и их всё равно придётся долго решать.

Как тут уже писали: dlopen, запуск других программ, конфиги и взаимное расположение бинарника и прочих ресурсов, и наверняка куча каких-нибудь других мелких нюансов.

Забыл добавить: это не теоретические измышления, а следует из практических попыток делать docker образы минимального размера на основе scratch/distroless базовых образов: пока подберёшь все необходимое, потратишь несколько дней. Хуже всего, что сначала может казаться, что оно работает, а через несколько часов или дней вывалиться, потому что не нашло какой-то ресурс, который грузится не сразу.

В проекте AppImage есть https://github.com/AppImageCommunity/pkg2appimage

docker build .

exodus, но сам не пробовал.

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

О, а вот это то, что надо.

Сама идея драть зависимости из пакетов! ( забавно, я свой велосипед тоже на луа писать начал :) )

Ща я допилю рекурсивность – будет то, что надо

Если нужно делать это регулярно и для многих программ, то проще повеситься

не, не регулярно и только для нескольких

docker build .

?

А что будешь делать, если часть вытащенных *.so на целевой системе уже присутствует?

хуже года целевые so разных версий :)

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

Может чрут или даже джокер - посмотрим

Джокер?

Докер. Клятая андроидская клава!