Ня

Годно, нужно. Правильная ссылка на новость: https://lists.ubuntu.com/archives/snapcraft-announce/2016-August/000000.html

спасибо

Негодно и ненужно. Для личных нужд есть cde, а для публичных не фиг трояны распространять.

Годно, нужно.

Тащить говно стало еще проще, ага.

Когда они мусор со своего снаф репозитория почистят?

правильный snap это msi

Всем вышеотписавшимся табуретки из чугунины за мой счёт!

SNUFFCRAFT

А я было подумал, что это какой-то новый крутой форк майнкрафта. Ай, ну вас с вашим каноникалом.

А его кто-нибудь уже заюзал из известных проектов? Или убунтовцы сами придумали и сами пилят?

а есть тут кто-нибудь кто в теме? они планируют сделать чтобы можно было использовать системные библиотеки, вместо того чтобы тащить с собой GTK? и доступ к файловой системе. естественно, с разрешения юзера после соответствующего запроса.

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

перепробовал все описанное в документации, ничего не помогло. (16.04)

ну и с GTK тоже непонятно как.. плеер умеет одновременно в GTK2 и GTK3 (переключение в настройках), и размер пакета становится чем-то вроде 100MB или больше. дикость же?

дикость же?

Музычку на удаленный сервачёк: ведь 21 век на дворе, в любом захолустье гворят широкополосный безлимитный интернет почти за спасибо.

Размер пакета большой? Сколько? 100 метров? Да вы, батенька, скупердяй. В нормальных телефонах уже памяти больше сотни гигов, ерунда какая.

понятно, что я издеваюсь. Но это же убунта, медведь не сдох — продукт не юзабельный. Всё как обычно.

но мне не удается сделать чтобы deadbeef из snap имел возможность грузить музыку с харда..

VLC из снапа как-то умеет, правда там разрешения apparmor прописаны такие, что он даже по симлинкам пройти не может. Посмотри, как там сделано?

и размер пакета становится чем-то вроде 100MB или больше. дикость же?

Нет. Цель снапов — создавать переносимые приложения, которые тащат всё своё с собой. Тот же VLC весит 111Мб.

Догнали и перегнали GNOME Sandbox! Причём не привязали ни к Wayland, ни к GNOME.

Цель снапов — создавать переносимые приложения, которые тащат всё своё с собой.

хм.. даже GLIBC? инфа 100%?

ну ладно, допустим.. но зачем блокировать доступ к системному GTK?

продукт не юзабельный. Всё как обычно.

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

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

VLC из снапа как-то умеет, правда там разрешения apparmor прописаны такие, что он даже по симлинкам пройти не может. Посмотри, как там сделано?

а не подскажешь где именно смотреть?

хм.. даже GLIBC? инфа 100%?

Не копал так глубоко.

ну ладно, допустим.. но зачем блокировать доступ к системному GTK?

Затем, чтобы snap, собранный в 16.04, без изменений работал в 18.04, в котором будет куда более свежая GTK, которой гномеры опять поломают какой-нибудь кусок API.

а не подскажешь где именно смотреть?

Ну в /snap/vlc/1/meta/snap.yaml наверное, snap же из него собирается :-)

Судя по всему, там используется плагин home, дающий право открывать файлы из домашнего каталога.

Не копал так глубоко.

ну ты эта.. уточни там.. а то мне слабо верится.

Затем, чтобы snap, собранный в 16.04, без изменений работал в 18.04, в котором будет куда более свежая GTK, которой гномеры опять поломают какой-нибудь кусок API.

это не катит за причину. хочу стрелять в ногу.

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

Судя по всему, там используется плагин home, дающий право открывать файлы из домашнего каталога.

я это, естественно, тоже использую, и даже делал

sudo snap connect deadbeef:home ubuntu-core:home

Ну в /snap/vlc/1/meta/snap.yaml наверное, snap же из него собирается :-)

а откуда этот файл взять? у меня щас нет линукса под рукой.

а откуда этот файл взять?

sudo snap install vlc :-)

Ну или я могу его просто положить здесь для тебя: http://pastebin.com/apnG6jca

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

Попробуй flatpak. Там тоже нельзя использовать системные либы, но есть что-то типа фреймворков, где уже собрали основные библиотеки. Соответственно там каждому пакету не нужно тянуть свой GTK.
В Снапе вроде как тоже есть похожая система (плагины), но, видимо, её ещё не допилили.

собранный в 16.04, без изменений работал в 18.04,

а в обратную сторону оно сможет? Собранный на 16.04 запустить на 14.04? Во что в итоге упрётся? В ядро?

ок. значит я все делаю правильно, и оно просто не работает конкретно у меня. будем ждать фиксов snapd.

тут вся суть в том, что мне _вообще_ не нужно тянуть никакой GTK — программе достаточно того, что уже установлено в системе.

разве бывают десктопные линуксы, где нет GTK? (ну кроме особо кастрированных тулкитофобских gentoo и подобных).

deadbeef предлагает на выбор использование GTK2 или GTK3, или, если нет ни того, ни другого — будет работать в консоли без гуя вообще.

вторая проблема — это доступ в $HOME для загрузки 3rd party plugins. это вообще непонятно как решать в рамках snap.

интересно, разработчики snap и flatpak вообще учитывали такой use-case?

вторая проблема — это доступ в $HOME для загрузки 3rd party plugins. это вообще непонятно как решать в рамках snap.

Про GTK ничего не скажу, а про 3rd party — у пользователя появляется ~/snap/your_app_here/1/... в которой повторены все его файлы настройки, например .config, .cache, .local. Кладите плагины туда.

Точнее, это произойдёт автоматически, если snap приложение пишет в ~.

ок, спасибо за инфу. как только решится вопрос с доступом к FS и системному GTK — попробую :)

Название звучит как видеоигра в пакеты.

хочу стрелять в ногу.

тогда зачем пользоваться snap? он не для того.

Для доступа к GTK подключите part desktop-gtk2. Подключение партов вроде ubuntu-core НЕ включает их внутрь snap, они поддержваются и скачиваются при необходимости на хосте, фактически это и есть системные библиотеки, парт будет смонтирован в виде /snap/ubuntu-core и будет переиспользован всеми снапами.

Посмотрел VLC, /snap/vlc/current/lib/x86_64-linux-gnu занимает 5мб, остальное это сам VLC. Так что никаких объемных системных библиотек сам снап не включает, только ссылается на parts.

И угадай, какие там внутри интересные библиотеки есть:

20:00 aceler@Compy:/snap/vlc/current/usr/lib/x86_64-linux-gnu $ cd 
alsa-lib/       glib-2.0/       mesa/           samba/
avahi/          gtk-2.0/        mesa-egl/       x264-10bit/
caca/           gtk-3.0/        openssl-1.0.0/  xorg/
dri/            krb5/           pulseaudio/     
gdk-pixbuf-2.0/ libgtk2.0-0/    qt5/            
gio/            libgtk-3-0/     qtchooser/     

Всё своё ношу с собой.

Проект спонсируют производители SSD?

Действительно, посмотрел lib, а не usr/lib. Дублирование у VLC присутствует.

тогда зачем пользоваться snap? он не для того.

ну я не считаю правильным, что snap решает эти вещи за меня. как он решает, какие библиотеки системные, а какие нет?

например, glibc надо с собой тащить или нет? и если не надо — то тогда почему GTK надо? в чем разница?

Для доступа к GTK подключите part desktop-gtk2. Подключение партов вроде ubuntu-core НЕ включает их внутрь snap, они поддержваются и скачиваются при необходимости на хосте, фактически это и есть системные библиотеки, парт будет смонтирован в виде /snap/ubuntu-core и будет переиспользован всеми снапами.

ок, я всенепременно попробую это, хотя мне кажется что я уже это пробовал, и это не совсем так сработало, как вы описали.

но возникает закономерный вопрос, как быть с GTK3? приложение дает пользователю выбор предпочитаемого им тулкита. например, я сам предпочел бы GTK2 по ряду причин. но даже среди разработчиков deadbeef есть люди предпочитающие GTK3. как тут быть?

можно ли как-то одновременно сделать part desktop-gtk2 и part desktop-gtk3?

snap собирается под определённую версию ubuntu-core. При установке snap-пакета, собранного под более новую версию системы, в систему будет установлен более новый пакет ubuntu-core. Так что проблем с обратной совместимостью я что-то не вижу.

хм.. даже GLIBC? инфа 100%?

GLIBC нет — эти библиотеки есть в отдельном снапе ubuntu-core. Там же, кроме glibc, есть ещё куча отдельных библиотек и программ. Весит порядка 70 Мб — т.е. это далеко не вся система.

ну ладно, допустим.. но зачем блокировать доступ к системному GTK?

В snap блокирован доступ к системному чему-бы-то-ни-было. Чтобы пользоваться только тем, что доступно внутри snap. Ибо безопасность, неконтролируемое распространение бинарников и вот это всё :-)

GLIBC нет — эти библиотеки есть в отдельном снапе ubuntu-core. Там же, кроме glibc, есть ещё куча отдельных библиотек и программ. Весит порядка 70 Мб — т.е. это далеко не вся система.

а, ну ок, т.е. когда-нибудь они могут подобное и для GTK прикрутить.

будем наблюдать за развитием событий. я даже какой-то блог-пост про это нашел: https://developer.ubuntu.com/en/blog/2016/07/06/announcing-new-snap-desktop-l...

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

но это все равно не отвечает на вопрос — как поддерживать одновременно GTK2 и GTK3?

если юзер положит в ~/snap/your_app_here/1/ плагин реализующий поддержку Qt — это в рамках snap работать в принципе никак не может?

если юзер положит в ~/snap/your_app_here/1/ плагин реализующий поддержку Qt — это в рамках snap работать в принципе никак не может?

Не знаю, не пробовал.

Я бы на вашем месте сделал отдельные пакеты -gtk2 -gtk3 и -qt и пусть пользователь выбирает сам.

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

пример:

юзер идет на сайт, качает плагин для вывода звука через jack, и кладет в правильное место (~/snap/your_app_here/1/), но пакет snap не ставит jack, и доступа к нему быть не может. и ничего не сделать, ведь даже в отдельный snap запихать этот плагин не получится?

Я бы на вашем месте сделал отдельные пакеты -gtk2 -gtk3 и -qt и пусть пользователь выбирает сам.

ты не понял. плагин, реализующий (и требующий) Qt — сторонняя разработка. я даже не могу знать какая версия Qt ему может понадобиться.

на момент создания snap-пакета — я даже могу не знать, что такой плагин существует, или будет существовать.

я попробую написать им в mailing list укороченную версию этих вопросов. думаю, что предложат идти лесом^W^W продолжать юзать tar.bz2.

тут вся суть в том, что мне _вообще_ не нужно тянуть никакой GTK — программе достаточно того, что уже установлено в системе.

Т.е. ты гарантируешь, что deadbeef заведется с любой версией GTK, так? Даже с теми, которые ещё не вышли? Если прямо так - ну что ж, могу только позавидовать :)
Просто это очень редкий юзкейс. Обычно есть набор версий ПО, с которыми всё гарантированно работает (например, программист использует их при написании кода). Есть версии, которые вроде как поддерживаются, но тестирование с ними проводят весьма эпизодически. Есть версии, с которыми проект вроде как собирается, но заработает ли - непонятно. И чтобы не гадать, нормально ли будет работать проект с libfoo версии bar, предлагается жестко задавать версию GTK (да и других библиотек) и носить её с собой.

разве бывают десктопные линуксы, где нет GTK? (ну кроме особо кастрированных тулкитофобских gentoo и подобных).

Могут быть проблемы с разрядностью. Т.е. GTK есть, но для другой архитектуры. Или собранный как-то криво. Для x86 это вряд ли будет проблемой, а вот для какого-нибудь ARM есть куча вариантов сборки.

Т.е. ты гарантируешь, что deadbeef заведется с любой версией GTK, так? Даже с теми, которые ещё не вышли? Если прямо так - ну что ж, могу только позавидовать :)

гарантировать - не может никто. но обратного пока не случалось, за всю историю проекта. т.е. можешь взять билд deadbeef от 2010 года и запустить, и да, он будет работать.

ну или наоборот, можешь взять свежий вчерашний билд, и запускать на убунте 8.04.

И чтобы не гадать, нормально ли будет работать проект с libfoo версии bar, предлагается жестко задавать версию GTK (да и других библиотек) и носить её с собой.

да, я и сам именно так и поступаю. библиотеки со стабильным API (GLIBC, GTK, PulseAudio и подобные) — использую системные. те, у которых нет стабильного API, или которые нужны фиксированной версии - тащу с собой.

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

ну для 32 и 64 бит я отдельные билды делаю, само собой.. а разве есть snap для 32 бит?