LINUX.ORG.RU

FFmpeg вернётся в репозитории Ubuntu 15.04

 ,


1

1

Из-за конфликта среди разработчиков, в 2011 году FFmpeg был форкнут и появился libav. Многие пользователи, однако, предпочитают использовать именно FFmpeg, поскольку его создатели активно портируют улучшения из libav (в отличие от разработчиков libav, которые игнорируют развитие конкурента). Подробности о взаимоотношениях этих проектов здесь или здесь.

Уже на протяжении нескольких лет в стандартных репозиториях Ubuntu доступен лишь libav (по слухам, причина этого в том, что мейнтейнер пакетов FFmpeg оказался сторонником лагеря libav). Ситуация изменится, начиная с Ubuntu 15.04, выпуск которой запланирован в апреле будущего года.

Поскольку имена библиотек FFmpeg и libav совпадают, для бесконфликтного сосуществования этих пакетов в системе пакет FFmpeg будет использовать именование библиотек вида «libavdevice-ffmpeg», «libavutil-ffmpeg».

>>> Подробности

anonymous

Проверено: Shaman007 ()

Ответ на: комментарий от LongLiveUbuntu

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

я может и сменю железо на локалхосте, а на серверах все равно виртуалки, там железо роли не играет.

prizident ★★★★★ ()
Ответ на: комментарий от i1atf

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

FFmpeg

Тонко.

h578b1bde ★☆ ()
Ответ на: комментарий от prizident

у нас вот есть немало систем на RHEL4, которые уже отработали лет 8 и еще спокойно столько же отработают. и между патчить руками и написать yum update разница в человекочасах.

RHEL — платный дистр, не? Сравнение с бесплатным некорректно.

И потом, обновлять всё равно придётся и через 12 лет это будет менее тривиально.

в крупных датацентрах уже давно используют виртуалки. а если не виртуалки, то перенести линукс с одного сервака на другой дело 15 минут.

Я знаю. И что, к чему это было сказано?

Во-первых работает - не трогай это золотое правило.

Только у русских. Им лишь бы не работать, заранее ни о чём не позаботятся. Пока гром не грянет…

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

Ну и? При этом на древних дистрах относительно мало кто сидят.

i1atf ()
Ответ на: комментарий от Kroz

Ты ничего не напутал?

Нет, поставиться в /usr это насрать в систему. Например, в линуксе две программы могут использовать разные библиотеки с одним именем, но по разным путям. Искать причины глюков в таком треше месяц будешь.

Тогда тебе не нравится концепция модульности.

При чем тут модульность?

Зато каждый софт не городит свои велосипеды, а использует нормальные решения,

Если я вместе со свой программой ношу свою сборку boost, ffmpeg и прочих библиотек, то я уже делаю велосипед?

которые, к тому же, регулярно обновляются.

Вместе с поломкой половины софта. Если программа писалась и тестировалась под библиотеку версии X.Y, то нельзя так просто взять и обновить эту библиотеку до версии X.{Y+1}, а про {X+1}.Z я вообще молчу. Никто работоспособность такого франкенштейна гарантировать не может. Этим пытаются заниматься майнейнеры дебиана, да, в плане работоспособности у них что-то получается, но только вот пользоваться этим невозможно из-за того, что всё тухлое и не актуальное.

Reset ★★★★★ ()
Ответ на: комментарий от Deleted

«Опенсорч» тем и хорош, что никто никого не принуждает делать то, что ему не нравится, не хочется

А пользователей проприетарного ПО держит на прицеле рота спецназа?

или просто то, на что нет времени.

Tell me moar.

h578b1bde ★☆ ()
Ответ на: комментарий от Reset

Если я вместе со свой программой ношу свою сборку boost, ffmpeg и прочих библиотек, то я уже делаю велосипед?

Нет. Просто когда в boost найдут критическую дыру, и все нормальные системы обновятся за 1-3 дня, а ты в это время будешь на Багамах картошку копать, админы будут тебе посылать лучики сам знаешь чего за то, что ты тормозишь с обновлением своей комбо-программы, и люто недоумевать, почему бы тебе не поступить как все нормальные люди и не использовать общие библиотеки которые давно обновились.

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

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

Если программа писалась и тестировалась под библиотеку версии X.Y

То это прописывается в пакете. И данная библиотека просто не обновляется - пакетный менеджер побеспокоится. Ну, а если обновление и вправду важно, то в систему просто поставится две версии библиотеки. Ты никогда не интересовался как библиотеки называются, в смысле файлы?

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

Ты живешь в каком-то неправильном мире. У меня всё работает и кушать не просит, и это при том, что я использую testing ветку, rolling release дистр и не всегда официальные репозитории.

Ты, проблемы решать пробовал?

Kroz ★★★★★ ()
Ответ на: комментарий от Kroz

Просто когда в boost найдут критическую дыру, и все нормальные системы обновятся за 1-3 дня,

Это те системы, которые фризят версии пакетов на полгода, а кто и больше?

Что-то я подозреваю, что шустро обновятся только если это будет какая-то громкая уязвимость и скандал, а в остальных случаях будут неделями/месяцами собирать пакет и сраться в багзилле.

Ну арч какой-нибудь шустро обновится, да

У меня всё работает и кушать не просит, и это при том, что я использую testing ветку, rolling release дистр и не всегда официальные репозитории.
У меня все работает

Это вообще не аргумент. По многим причинам

Midael ★★★★★ ()
Последнее исправление: Midael (всего исправлений: 2)

Все ж хоть и с названиями, но libav таки поднасрал)

Может, они тогда одумаются и еще systemd выкинут на хрен, пока это не зашло слишком далеко? :)

Indexator ★★★ ()
Ответ на: комментарий от h578b1bde

А пользователей проприетарного ПО держит на прицеле рота спецназа?

Не передергивай.

Deleted ()
Ответ на: комментарий от Kroz

Ты, проблемы решать пробовал?

Он их не решает, а создает :)

Deleted ()
Ответ на: комментарий от Midael

Ну арч какой-нибудь шустро обновится, да

И эти же люди говорят об отсутствии работоспособности репозиториев. Там же толком тестирования нет :) Зато быстро.

Deleted ()
Ответ на: комментарий от Midael

Это те системы, которые фризят версии пакетов на полгода, а кто и больше?

This:

если это будет какая-то громкая уязвимость

А на мелкие - да, совместимость дороже.

Это вообще не аргумент. По многим причинам

Не аргумент, правда. Просто говорю, что это возможно. Это к тому, что вероятно (и скорее всего) причина в том, что человек просто не пытался решать проблемы. Нытиков нынче много. Общих слов от таких много, а конкретики - мало. Вот и пытаюсь спровоцировать на конкретику.

Kroz ★★★★★ ()
Последнее исправление: Kroz (всего исправлений: 4)
Ответ на: комментарий от cipher

У кого? Проприетарщины в разы больше, так что

В разы больше на линуксе?

Deleted ()

Да неужели!? Слава богам.

h4tr3d ★★★★★ ()
Ответ на: комментарий от I-Love-Microsoft

У меня вылазили. Некоторое время назад в Libav не было референсинга у AVFrame/AVPacket, что оказалось удобным. Были проблемы с RTMP, как на play, так и на publish. Сейчас не знаю, т.к. забил на совместимость с libav и пользуюсь ffmpeg (на работе). В Mint/Ubuntu можно вытянуть из репозитория samrog131, для дебиан, разной свежести, всегда было в deb-multimedia.org

h4tr3d ★★★★★ ()
Ответ на: комментарий от iVS

с точки зрения пользователя - пофиг. С точки зрения программиста: настраивается через alternatives, так что - тоже пофиг.

h4tr3d ★★★★★ ()
Ответ на: комментарий от anonymous

Не устану повторять: проект FFmpeg был в стагнации, собственно это и привело к бурлению говен и появлению libav. Но вместо вменяемых разработчиков там собрались одни истерички. А само явление стало пинком под зад гордой птице FFmpeg, после чего она таки полетела, и хорошо так полетела: и код причёсывается, и на косяки быстро чинятся, и фичи делаются. Есть некоторый градус жлобства в рассылке (проявляется в on-top answer, вместо inline), но... это их правила. Мой патчик для фикса утечек файловых дескрипторов в RTMP быстро приняли (правда там одна строчка :)). Всё не соберусь отправить поддержку проигрывания RTMP и вещания через HTTPS прокси.

h4tr3d ★★★★★ ()
Ответ на: комментарий от aidan

Ага, пришлось так и делать для OpenCV. Пичалька.

h4tr3d ★★★★★ ()
Ответ на: комментарий от Polugnom

Нидермайеру, кстати, респект. Кровь пролилась, но выводы, в результате, правильные сделал. Но самое событие эпичненькое было. Читаешь старые хроники, аж дух захватывает.

h4tr3d ★★★★★ ()
Ответ на: комментарий от duger

Всё это верно, но если кто-то не желает пользоваться актуальными версиями ПО(или не может, по какой-то причине) - он должен иметь возможность юзать то, что ему хочется юзать. Пусть и протухшее.

lucentcode ★★★★★ ()
Ответ на: комментарий от Deleted

В разы больше на линуксе?

Вполне возможно. Андроидов дофига и больше.

cipher ★★★★★ ()
Ответ на: комментарий от Kroz

Просто когда в boost найдут критическую дыру, и все нормальные системы обновятся за 1-3 дня, а ты в это время будешь на Багамах картошку копать, админы будут тебе посылать лучики сам знаешь чего за то, что ты тормозишь с обновлением своей комбо-программы, и люто недоумевать, почему бы тебе не поступить как все нормальные люди и не использовать общие библиотеки которые давно обновились.

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

То это прописывается в пакете.

Это касается _всех_ программ. Ты предлагаешь во всех пакетах так прописать?

И данная библиотека просто не обновляется

И получаем проблему, которую ты описал выше.

Ты никогда не интересовался как библиотеки называются, в смысле файлы?

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

Ты, проблемы решать пробовал?

Проблемы концептуальные, их не мне решать надо.

Reset ★★★★★ ()
Ответ на: комментарий от dearboy

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

arcanis ★★★★ ()
Ответ на: комментарий от Reset

отвечу на это сообщение =)

Есть такая тулза, называется sage. В оригинале это как раз твой любимый self-contained пакет, который тащит все свое, начиная от компиляторов. И он имеет ряд проблем, которые не возникают у нормальных приложений:

1. Абсолютно непрозрачная система сборки. Ну то есть от слова совсем. Процесс сборки практически нереально контролировать. А, прикинь, бывают юз кейсы, когда тебе надо что то изменить (например убрать какую либо оптимизацию).

2. Размер. Да, детка, эта херня весит 2.5Г в распакованном виде. А вот полезной инфы там примерно метров 300. Не то, чтобы мне было жалко места, но если пересчитать в процентах для всех приложений, то размер моего рута вырастет на 110Г. Я думаю, я могу найти им лучшее применение.

3. Supported architectures, если ты говоришь о скачивании готовых бинарников с сайта. Afair ARM в них не входит, хотя под ним работает.

4. Твоя любимая линковка с приложениями определенных версий. Ты можешь ознакомиться, например, с этим багом. В твоей логике получается ради этой херни я должен тащить cairo собранный с определенной версией freetype твердости говна мамонта.

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

arcanis ★★★★ ()

Ну как-то не особо радует. У меня вон есть опера, для которой нужен определённый ffmpeg. И что делать?

anonymous ()
Ответ на: комментарий от Reset

Такое обновление не решает вопросов безопасности вообще.

Еще и как решает. Ты обновляешь библиотеку, возможно перекомпиливаешь некоторые программы (заметь, без вмешательства авторов программ) - готово. В твоем сценарии при нахождении критической проблемы и выпуска новой версии библиотеки все авторы программ должны пересобрать пакеты: как ты собираешься их всех организовать?

> То это прописывается в пакете.
Это касается _всех_ программ. Ты предлагаешь во всех пакетах так прописать?

Внезапно, это уже сделано! Открой пакет своего любимого дистра и там прописаны зависимости.

И данная библиотека просто не обновляется

И получаем проблему, которую ты описал выше.

Печитай еще раз тот мой пост, и желательно еще пару строк ниже этого предложения.

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

Конкреный пример будет, или опять сосед напел?
Как раз дистростроители и обеспечивают чтобы не было конфликтов. Поэтому, если мы берем именно дистрибутив, то конфликтов нет.

Ты, проблемы решать пробовал?

Проблемы концептуальные, их не мне решать надо.

Это ты 10 лет пропработал бок-о-бок с Линусом, потом столько же в Red Hat, потом написал пару книг по Линуксу, и наконец, небезосновательно предположив, что Линукс ты наверное, все же немного понимаешь, на основании такого недюжего опыта пришел к такому решению? Думаю, нет. Так и скажи - не решал, а просто посчитал себя самым умным.

Kroz ★★★★★ ()
Ответ на: комментарий от Kroz

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

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

Внезапно, это уже сделано! Открой пакет своего любимого дистра и там прописаны зависимости.

Внезапно, они прописаны в виде >=, а это не работает.

Конкреный пример будет, или опять сосед напел?

С libpng было что-то подобное, но самый громкий пример это изменение поведения memcpy в glibc от которого пострадало куча софта.

Как раз дистростроители и обеспечивают чтобы не было конфликтов. Поэтому, если мы берем именно дистрибутив, то конфликтов нет.

А в подходе нормальных ОСей конфликтов не будет в принципе, а не потому что дистростроители подвели весь софт под общий знаменатель.

на основании такого недюжего опыта пришел к такому решению? Думаю, нет.

Конечно. Мое решение основано на 15 лет опыта работы с линуксом и пришел к нему я относительно недавно. Лет 5 назад я бы нес ту же чушь, что и несешь ты.

Reset ★★★★★ ()
Ответ на: комментарий от Reset

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

Устранение багов поведение не меняет. На то оно и устранение багов. И разработчики обычно проводят соотв. тестирования. А если оно изменило поведение - это баг, который опять-таки решается разрабочиками библиотеки.

Внезапно, они прописаны в виде >=, а это не работает.

Ох уже этот максимализм.
1) Когда так прописано - работает.
2) Когда важна ветка - прописывают ветку. Например, mc зависит от «>=dev-libs/glib-2.8:2» - то есть любая версия выше 2.8, но меньше 3.0. В Libreoffice есть такая зависимость: dev-java/rhino:1.6, то есть 1.6.x.
А если у твоего софта не работает - прописывай конкретную версию, кто ж мешает?

А в подходе нормальных ОСей конфликтов не будет в принципе

Да ты что? И как, интересно ты это реализуешь? Как разработчики не общаяясь буду ибезгать конфлика имен?

Мое решение основано на 15 лет опыта работы с линуксом и пришел к нему я относительно недавно.

С каким Линуксом? С Убунточкой? Тыцанье по кнопкам много знаний не приносит.

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

Kroz ★★★★★ ()
Ответ на: комментарий от Kroz

Устранение багов поведение не меняет.

В идеале.

И разработчики обычно проводят соотв. тестирования.

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

К вопросу надо надо подходить не из идеалистических позиций, а с реалистических. Одним фиксом сразу исправить уязвимость в 100500 программах выглядит конечно красиво, но по факту имеем следующее. Пользователь имеет на машине не 100500 программ, а 2-3 (максимум 10, если он гик), если нам очень повезло, то эти 3 программы используют одну и ту же библиотеку (с точности до сборки), в библиотеке есть фичи A, B, C, уязвимость нашли в фиче A, в программах используются B и С и если оочень не повезло, то используется A и то не в программе, которая не установлена у пользователя. Что в итоге дает это «исправление»? По факту ничего кроме геморроя на задницу пользователя.

Когда так прописано - работает.

Не работает даже теоретически. В >= может прилететь новая мажорная версия со сменой ABI. Кое-какая защита от этого есть в rpm, но в dpkg полный трындец.

dev-java/rhino:1.6, то есть 1.6.x.

Это не конкретная зависимость. Инкремент x тебе не гарантирует работоспособность.

А если у твоего софта не работает - прописывай конкретную версию, кто ж мешает?

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

Как разработчики не общаяясь буду ибезгать конфлика имен?

Держать библиотеки в директории с программой. Внезапно, да?

С каким Линуксом? С Убунточкой? Тыцанье по кнопкам много знаний не приносит.

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

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

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

Reset ★★★★★ ()
Последнее исправление: Reset (всего исправлений: 1)
Ответ на: комментарий от Reset

Устранение багов поведение не меняет.

В идеале.

А в реале существует политика версий (формальная или не формальная) Release Notes, и багтрекер.

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

У мейнтейнера есть документация на софт, и он что-то меняет страясь не затрагивать поведение, описанное там; после изменений, по-хорошему, гоняет тесты. А «на реале» это «тестируют» дистростроители: этим (в частности) testing ветки отличаются от stable.

Что в итоге дает это «исправление»? По факту ничего кроме геморроя на задницу пользователя.

... в виде обновления, которое забирает время, но ничего не дает. Бинго! Это нужно вталдычивать всем тем, кто кричит «ааа, вчера вышла новая версия либы, а у меня ее до сих пор нет!!!», не понимают, что, кроме потери времени, оно, возможно, ничего не несет.
Оговорка: геморрой = потеря времени, что, слгласись, не так страшно. Хоть и не полезно.
Да, согласен! Небольшая потеря времени в виде скачивания и установки - минут 5 в день. Ужас, да?

Не работает даже теоретически. В >= может прилететь новая мажорная версия со сменой ABI

Еще раз: когда нужна мажорная вресия - ее фиксируют. Да загляни ж к себе на комп, у тебя стоит несколько версий Python и еще много чего!

Инкремент x тебе не гарантирует работоспособность.

См. про политику версий и багрепорт.

Что потом сломает мне установку другого софта

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

Держать библиотеки в директории с программой. Внезапно, да?

Внезапно. Мне нужна либа glibc: в какой директории прикажешь мне ее искать?

Личностные закидоны не комментирую.

Kroz ★★★★★ ()
Ответ на: комментарий от Kroz

А в реале существует политика версий (формальная или не формальная) Release Notes, и багтрекер.

И в результате надо тратить кучу человекоресурсов на чтение этой фигни, а всё только для удовлетворения ЧСВ майнейнеров, которые мнят себя разработчиками. В идеале только разработчик должен это всё читать и принимать решение об изменении используемых библиотек.

У мейнтейнера есть документация на софт

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

Да, согласен! Небольшая потеря времени в виде скачивания и установки - минут 5 в день. Ужас, да?

Конечно. Зачем это нужно ты объяснить можешь?

Да загляни ж к себе на комп, у тебя стоит несколько версий Python и еще много чего!

Которая фиксируется в имени пакета. Офигенно! И это опять же на усмотрение майнейнера и «политик» дистрибутива, на которые может быть положен большой и толстый в случае установки из ppa.

а значит к диапазону.

Я же уже сказал, что это не работает. Минорная версия не гарантирует неизменности поведения. Один баг могут пофиксить, а 100500 добавить.

Мне нужна либа glibc: в какой директории прикажешь мне ее искать?

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

Reset ★★★★★ ()
Ответ на: комментарий от Reset

Мое решение основано на 15 лет опыта работы с линуксом и пришел к нему я относительно недавно.

А чушь несешь, словно и 15 не прошло :)

Deleted ()
Ответ на: комментарий от Deleted

Пока я вижу чушь со стороны своих оппонентов.

Reset ★★★★★ ()
Ответ на: комментарий от Reset

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

Всё как-то мутно и невразумительно. Конкретные проблемы приведи, а не претензии а-ля «Тут у вас неправильно, не так как в винде».

Минорная версия не гарантирует неизменности поведения. Один баг могут пофиксить, а 100500 добавить.

Это и в оффтопике так же, и не работает :) Как там, в восьмерочке, починили баг с утечкой памяти при полной проверке диска (со времен семерочки) или вообще новые баги добавили?

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Reset

Пока я вижу чушь со стороны своих оппонентов.

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

Deleted ()
Ответ на: комментарий от Deleted

Сказано же, так нельзя делать,

Это не аргумент

небезопасно и оверхед в реализации излишний.

Эту чушь я выше опроверг.

Reset ★★★★★ ()
Последнее исправление: Reset (всего исправлений: 1)
Ответ на: комментарий от Deleted

А вообще: Reset-ушка приводит в пример ведроид, но, видимо, он совсем не в курсе ситуации с «безопасностью пакетов» в нем. Ещё будут примеры успешных форматов :) ? И чем репозитории тогда хуже этого вашего гугломаркета?

Deleted ()
Ответ на: комментарий от Deleted

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

Reset ★★★★★ ()
Ответ на: комментарий от Reset

Это чушь я выше опроверг.

Значит плохо стараешься, раз никто не понял твои опровержения. Попробуй ещё =)

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Кому надо всё поняли, отмотай на несколько страниц вверх, там есть те, кто согласился с моим мнением. Ты не понял лишь потому что не хочешь понять.

Reset ★★★★★ ()
Ответ на: комментарий от Reset

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

Касается отчасти. Репозиторий и гугломаркет - технически одно и тоже.

Deleted ()
Ответ на: комментарий от Deleted

Репозиторий и гугломаркет - технически одно и тоже.

Тебе еще раз перечислить мои претензии к репозиториям или сам отмотаешь и прочитаешь? Если кратко, то внутри может быть оно и одно и тоже, а подача разная и сделаны эти механизмы по сути для различных целей. Это так можно и %%% с пальцем сравнить.

Reset ★★★★★ ()
Ответ на: комментарий от Reset

Кому надо всё поняли,

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

Ты не понял лишь потому что не хочешь понять.

Я понял одно: Тебе нужно «в-одном-пакете» вместо работоспособного софта :)

Deleted ()
Ответ на: комментарий от Reset

после последней истории с Дебианом (интеграция системд) вот с этим склонен согласиться, у большой пакетной базы оказывается тоже свои минусы - слишком много людей с разными взглядами, проект стал плохо управляем

но массовый софт тоже паковать надо (думаю, система в которой чтобы элементарно зайти почитать интернет или проиграть видео, надо вручную собрать кучу пакетов, мало кого привлечет), но наверное, лучше это делать в отдельных репозиториях, можно например по темам: debian-multimedia, debian-office и тп

anonymous ()
Ответ на: комментарий от AHAH

Затем, что скомпиленный тобой он новее :) Да и специфичные ключи можно задать.

peregrine ★★★★★ ()
Ответ на: комментарий от Reset

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

Подожди, ты же вроде отстаивал точку зрения пользователя, так не всё ли равно, если ты пользователь, в каком виде подается ПО. Работает и ладно. Ты в убунточке же не без софта работаешь, правильно? Вот. Будем считать, что ты понял :)

Deleted ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.