Opera теперь со вкусом snap

Canonical лепит заранее ffmpeg кучу версий. Опоздание и не выкладывание самых новых версий для Chromium Dev — не критично.

Разработчики Opera уже при выкладыаании берут нужную версию.

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

Только сейчас есть один момент: ментейнеры убунту собирают chromium для определённых версий билдов, номера которых не всегда совпадают с номерами тех версий chromium, которые берутся как основа сборки очередной версии opera. Поэтому не всегда заранее собранный пакет кодеков по номеру версии будет совпадать. К тому же иногда совместимость ломается (или что там происходит) и для взятых у убунты кодеков, казалось бы вполне совместимой версии, opera отказывается нормально с ними работать.

Никакой разницы в какой момент собирается кодек до выхода новой версии или во время нет - это не такой долгий процесс.

почему-то всех этих проблем нет у установщика steam («тысячи их»), бинарника openoffice (deb прекрасно работает в Ubuntu, Debian; rpm - в Rosa, CentOS, Gentoo), opera (Rosa, Gentoo), aftershort pro (CentOS, Rosa).

Если система пакетирования позволяет создавать «мета-пакеты», то проблема распихивания как правило решается во время установки, не говоря о том, что никто не отменял запихивание всего хозяйства в /opt.

если твоё ПО использует dracut — это специфика

Если разработчик затачивает свою софтину под «определённый» дистрибутив, то дальнейшее его или пользователей удивление факту того, что где-то что-то не работает можно даже не принимать во внимание. Обычно официально подддерживается не больше 3-4, остальные «сами собирайте» или «мы поддерживаем только эти».

почему-то всех этих проблем нет у установщика %app_name%

и что? не, серьёзно, а что ты этим хочешь сказать?

не говоря о том, что никто не отменял

никтонеотменяние можно как-то избежать? никто не отменял не использовать линукс вообще, дальше что?

под «определённый» дистрибутив

Ты случаем не разработчик виндоус-онли приложений? Это им обычно мерещится что существуют «определённые» дистрибутивы, а прошаренные ведь знают — это байки. кругом всё одинаковое и благорастворение. %app_name% можно поставить хоть куда без единой манипуляции с конфигами. </sarcasm>

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

не, серьёзно, а что ты этим хочешь сказать?
короче, поинт твой в чём?

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

Персонализирую: стремление запихнуть все приложения в snap не идея не очень хорошая, на мой взгляд, так как приведёт просто к быстрому забиванию дискового пространства. Не надо искать панацею в избавлении от традиционного подхода подготовки пакетов. Тем более, что большинство адекватных разработчиков прекрасно справляются с подготовкой одного deb-пакета и в дополнение к нему одного rpm-пакета, которых более чем хватает на уйму различных дистрибутивов.

кругом всё одинаковое и благорастворение

man LSB и твои волосы будут чаще мягкими и шелковистыми.
Как-то некоторым же удаётся неофициально поддерживать не только Ubuntu и CentOS.

Не надо искать панацею в избавлении от традиционного подхода подготовки пакетов

ну что за дихотомия очередная, вот такой бинарный подход мышления на лоре прям бесит.
я адвокатствую за избавление от традиционного подхода в отношении любого ПО которое используется в графическом окружении, а не за панацею какую-то.
почему только в «графическом»? да потому, что всё остальное и так уже в огромном кол-ве ставится на платформы а не голую ОС.

а насчёт дискового пространства

~$ ls -lha /var/lib/snapd/snaps/
-rw-r--r-- 1 root root 144M Aug  1 02:31 chromium_383.snap
...

~$ sudo apt install chromium-browser
...
After this operation, 221 MB of additional disk space will be used.

144M

221 MB

переживу как-нибудь.

я адвокатствую за избавление от традиционного подхода в отношении любого ПО которое используется в графическом окружении

это я в самом начале понял. Не надо мне такого, tar.gz или совсем уж а крайнем случае appimage более чем достаточно, если очень не хочется связываться с пакетный-менеджер-надстройка менеджером.

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

Скажи как сделать кучу версий пакетов для apt репозитория?

ЗЫ: вопрос больше риторический, ибо нормального решения нет

Так а кто мешал паковать кодеки в сам deb пакет? Вон Deadbeef так делает и ничего, работает без всяких снапов.

Лицензия. Если по простому (и то не совсем так) ты не можешь распространять h264 кодеки в коммерческом продукте без уплаты весьма сильного количества бабла.

почему-то всех этих проблем нет у установщика steam («тысячи их»), бинарника openoffice (deb прекрасно работает в Ubuntu, Debian; rpm - в Rosa, CentOS, Gentoo), opera (Rosa, Gentoo), aftershort pro (CentOS, Rosa).

забиванию дискового пространства

Как раз выше тобой названные продукты итак тащат кучу всего с собой и плевали на то, что есть в дистрибутивах.

Steam то с Ubuntu 12.04 кусков ушёл? А на 64 бита когда? 😀

Вот это круто, больше софта в самостоятельных пакетах это хорошо.

Может всё же разупороться и понять, что приложение, даже «консольное», которое весит сотни МБ не надо размазывать по ФС, а лучше складировать в одном месте?

Что до «гуйни», имеет смысл отделять ДЕ от основной ФС, но делать «диспетчер задач Гном» отдельным контейнером - шизофрения!

Скайпушка, Стимушка, Хромушка, Либро-офисушка... легион их, которые надо заворачивать в бочку и хранить отдельно.

То есть в snap освобождает от соблюдения лицензии?

Скажи как сделать кучу версий пакетов для apt репозитория?

http://archive.ubuntu.com/ubuntu/pool/universe/c/chromium-browser/

Не знаю насколько это нормальное решение. Я отсюда бинарные кодеки таскаю.

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

Steam шёл, а установщик нет.

И что такого в огромных количествах тянет opera, aftershot и бинарные openoffice из того, что есть в дистрибутивах.

Я. уточните уже столкнулся с тем, что у меня в виде одна софтина (свободная) тянула с собой системные библиотеки для винды (их так же тянет огнелис, громоптиц и java jre). Так вот, почему-то на одном из моих клипов это приложение падало при запуске, пока я одну из либо идущих в комплекте не переименовал, чтобы использовалась системная.

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

Я ещё понимаю, если в комплекте идут модифицированные библиотеки, как Qt в XnViewMP - тогда без их запихиваются со стандартными могут вылазить косяки.

Между прочим, Фороникс сообщает что Стим сообщил свою долю Линукса: 0,58->0,52

Нет. Просто кодеки позволено поковать некоммерческому дистрибутиву. Но не разработчику коммерческого браузера.

Это как бэ пакеты 📦 вместе со всех версий дистрибутивов, а не для одного.

Ты же понимаешь, что это лютый кал, который к тому же надо как-то подчищать

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

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

Я не предлагаю, так и сделали в snap пакете chromium-ffmpeg

То есть, если лицензия оперы позволяет перепаковывать их deb пакет, то сама убунту может для своего репозитория распространять пакет оперы с кодексом внутри? Отлично же, что немного лучше мета пакета, который тянет браузер и кодеки отдельно. Но тогда это можно делать и в рамках apt.

Но тогда это можно делать и в рамках apt

кем? кем это будет делаться?
вот скажи, тут чёт весь тред пытаешься рассказать что всё можно делать в рамках make install apt, при этом уже несколько раз упомянул Steam который работает по принципу snap
ты им пользуешься? тебе нравится мысль, что завтра Steam объявит о наборе мейнтейнеров криворуких Вуасянов из repack group, они будут делать сборки игр, а Valve будет контролировать релиз выхода новых версий и обновлений? если они посчитают, что DLC для твоей игры неочень, тебе придётся ждать примерно год.
это же всё можно сделать в рамках Steam.
я думаю тебе бы понравилось.

ты хочешь сказать, что в рамках snap есть возможность тащить кодеки отдельно из убунты (кто-то же занимается оформлением этого пакета), а в рамках deb-пакета нет?

стим сам не занимается упаковкой игр, очнись, это сервис, который предоставляет «издателю» инструменты распространения игр и контента к ним и если издатель посчитает, что dlc не очень, то тебе придётся ждать год, даже если оно будет распространяться не только через стим. И насколько качественно и кем упакованы игры ответственность несёт издатель.

А, ну ладно. Правда кто мешает паковать разработчику некоммерческого дистрибутива deb пакет со всеми кодеками всё равно не понятно.

То есть, если лицензия оперы позволяет перепаковывать их deb пакет

Нет. Opera EULA это не позволяет

ты хочешь сказать

где я что-то хочу сказать?

очнись

ещё раз прочти с

тебе нравится мысль, что завтра Steam объявит

откуда эта манера декларировать что? вот, стим так-то работает, а вот апт, он так-то работает. как с копипастой разговариваю.

тебе нравится мысль, что завтра Steam объявит

не объявит.

Давай по порядку, а то я уже смутно понимаю о чём обсуждение:

1. Snap-пакет в данном случае готовит разработчик Opera.

2. Тот же разработчик упаковывает deb и rpm пакеты.

3. Официально пакет opera в репозиториях Ubuntu не представлен.

4. По заявлению модератора в новости блога

It's worth mentioning that thanks to the efforts of the people at Canonical, the Opera snap will always be able to connect to the correct version of a video codecs package provided by Canonical. This will solve a lot of problems we've been having with having the 'right' video codecs on Linux.

то есть, каким-то образом snap тащит определённую версию кодеков (какую версию?) из реп или snap-репы от Canonical/Ubuntu. То есть здесь разработчики Opera зависят от разработчиков Canonical в плане совместимости браузера и версии кодеков.

5. Apt позволяет, если не ошибаюсь, работать с deb-пакетами, которые являются обёрткой/мета-пакетом для набора других пакето: в данном случае интересует пакет opera и пакет кодеков chromium-codecs-ffmpeg-extra подходящей версии, последний из которых опять же собирают разработчики Canonical.

6. Так как сами кодеки собираются на основе исходников chromium, как и сама opera, то, на первый взгляд, лицензия кодеков не должна запрещать сборку этих кодеков разработчиками Opera и выкладывать их в виде отдельного пакета (не в составе пакета браузера) в дополнение к пакету браузера.

Теперь два основных вопроса:

1. Что же всё-таки мешает разработчикам Opera выкладывать дополнительный пакет? Надо бы задать им этот вопрос.

2. Что мешает разработчикам Canonical сделать пакет-обёртку для установки браузера в комплекте с кодеками?

1. Лицензия

2. Нежелание городить костыли для одного и не самого популярного браузера

Что же всё-таки мешает разработчикам Opera

какая разница? ты акционер чтобы так волновал вопрос продвижения их софта?

Что мешает разработчикам Canonical

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

Лицензия

каким образом? То есть лицензия не запрещает Canonical (коммерческая организация) выкладывать этот пакет отдельным файлом, а другой коммерческой организации запрещает, это как?

Нежелание городить костыли для одного и не самого популярного браузера

То есть в рамках snap городить другие костыли у них желание возникло?

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

Забей, я просто завидую, что в генте нет официальной поддержки snap и я даже глянуть быстро не могу как это работает :)

Скажи как сделать кучу версий пакетов для apt репозитория?

Молча. Ничто не мешает собрать пакет так чтобы он ставился в /opt/производитель/продукт/версия.

Deb пакет также может содержать и статическую сборку приложения без зависимостей. Формат пакетов так-то вообще не очень важен, можно и просто тарболами обойтись.

И да, насчёт snap в gentoo (https://github.com/zyga/gentoo-snappy):

прелестно, прелестно: does it work without systemd? да и последний коммит в этот проект был 2 года назад

главное лишится зависимости от мейнтейнеров, а там хоть трава не расти.

Прост приходится использовать и snap, и flatpak, и appimage, т.к. авторы приложений кто распространяет в одном, кто в другом. Ладно ещё appimage, оно не заставляет ставить в систему что-то для запуска этих пакетов.

Я тут как-то пытался свежий гимп поставить, т.к. версия что в репах зависает при определённой операции (баги висят годами в багтрекерах и дебияна, и убунты, никто не пошевелился бекпортировать, всем пофиг. Мейнтейнерство зло), он у них во flatpak распространяется. Сперва пытался просто вытащить оттуда программу с зависимостями, распаковать в /opt и запускать с помощью LD_LIBRARY_PATH, но что-то нифига. Пришлось устанавливать всю хрень для запуска флатпаков :(

В snap нету костылей такого уровня по этому поводу

ЗЫ: там правда по другим хватает

В snap нету костылей по этому поводу

Как нет? А притягивание сторонних кодеков отдельной зависимостью?

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

Естественно, а на десктопе и PulseAudio требует 😮

Кошмар, да? 🤣

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

Братишки, свежий хлеб, сладкий хлеб, опера...

каким образом? То есть лицензия не запрещает Canonical (коммерческая организация) выкладывать этот пакет отдельным файлом, а другой коммерческой организации запрещает, это как?

Так Canonical за эти кодеки бабло 💶 платит, а Opera не хочет.

Так Canonical за эти кодеки бабло платит

вот это уже интересно