Лукас Решке (Lukas Reschke), отвечающий за поддержание безопасности свободной платформы для создания облачных хранилищ ownCloud (http://www.opennet.ru/opennews/art.shtml?num=40256),
потребовал (https://lists.ubuntu.com/archives/ubuntu-devel/2014-October/... у разработчиков Ubuntu исключить пакеты (http://packages.ubuntu.com/trusty/owncloud) с сервером ownCloud из репозиториев Ubuntu. Данное требование вызвано недостаточным вниманием к устранению уязвимостей в приложениях, представленных в репозитории universe.Обязательства по оперативному выпуску обновлений распространяется (http://en.wikipedia.org/wiki/Ubuntu_%28operating_system... только на репозитории "main" и "restricted", в то время как для "universe" компания Canonical не гарантирует обеспечение поддержки (за выпуск обновлений отвечает сформированное вокруг Ubuntu независимое сообщество). Большая часть репозитория "universe" близка по своему составу к официальным пакетам Debian, но пакеты с ownCloud поддерживаются силами сообщества Ubuntu. Длительное отсутствие обновлений для пакетов с ownCloud привело к нахождению в репозитории заведомо уязвимой версии, в которой остаются незакрытыми несколько критических проблем с безопасностью, позволяющих неаутентифицированному злоумышленнику получить полный доступ к серверу с правами пользователя, под которым выполняется ownCloud.
Так как отсутствует какая-либо активность по бэкпортированию исправлений
уязвимостей (http://owncloud.org/security/advisories) в ownCloud, разработчики проекта считают, что лучшим выходом будет удаление пакетов с сервером ownCloud из состава репозиториев для всех выпусков дистрибутива. Для установки ownCloud в Ubuntu предлагается использовать официальные deb-пакеты (http://owncloud.org/install/), распространяемые с сайта ownCloud. В качестве одного из возможных путей решения проблемы также упоминается подход дистрибутива Debian, который предлагает (https://packages.debian.org/wheezy-backports/owncloud) пользователям только самые свежие выпуски ownCloud через систему бэкпортов, не оставляя устаревшие версии в основном репозитории.
Marc Deslauriers из компании Canonical ответил (https://lists.ubuntu.com/archives/ubuntu-devel/2014-October/... что невозможно удалить пакеты из архива пакетов Ubuntu и предложил подготовить обновление с новой версией, бэкпортировать исправления, подготовить пустой пакет-заглушку, удаляющий программу на системах пользователей, или найти (https://lists.ubuntu.com/archives/ubuntu-devel/2014-October/... добровольца, готового сопровождать пакет. Такой подход не устроил (https://lists.ubuntu.com/archives/ubuntu-devel/2014-October/... разработчика ownCloud, который не считает, что на upstream должна ложиться забота по поддержанию патчей для сторонних пакетов в дистрибутивах. После некоторого упорства и угрозы включить предупреждение о сложившейся ситуации в руководство по установке ownCloud, разработчики Ubuntu удалили (https://bugs.launchpad.net/ubuntu/+source/owncloud/+bug/1384... пакет с ownCloud из репозиториев Ubuntu 14.10, непосредственно до объявления релиза. Для других выпусков утверждается (https://lists.ubuntu.com/archives/ubuntu-devel/2014-October/... что удалить пакеты невозможно, так как релизы уже выпущены.URL: https://lists.ubuntu.com/archives/ubuntu-devel/2014-October/...
Новость: http://www.opennet.ru/opennews/art.shtml?num=40921
можно просто ребрендить пакет в какой-нибудь clowncloud и добавить иконку горохового шута, да и всё...
Только при этом не забыть форкнуть, чтоб вопросов не было. Да и название понравилось, веселое такое ))
коммент месяца, однозначно
>можно просто ребрендить пакет в какой-нибудьчукча не читать, чукча писать! речь как раз о том что в убуньках этого делать некому, а пользователи в итоге попадают под удар. так-то можно просто обновлять пакет и все дела, но этого никто не делал и не собирался делать.
ownClown же! :-)
pwnClown судя по названию.
> можно просто ребрендить пакет в какой-нибудь clowncloud и добавить иконку горохового шута,
> да и всё...Типичное форковое мышление.
>> clowncloudЭто должен быть форк, переписанный на common lisp.
Модулем к емаксу?
>Модулем к емаксу?Батенька, а Ви таки видели ту заглушку на elisp->clisp в емаксе? Уровень задротства в Вашем сообщении надо таки увеличить вдвое против оригинала.
Забавная ситуация. Но тут уж ничего не поделаешь -- это обратная сторона модели репозиториев. Ну не бывает когда уж совсем всё хорошо. Так и репозитории обладают некоторой инерционностью и не могут обеспечить быструю смену версий.
А это общая проблема того что мейнтейнеры и разработчики - разные люди
Да. Но не правы здесь разработчики. Базовые знания уже решили бы 99% проблем.
А то любое веб приложение в репозитории возьми - они явно писались как проект который нужно куда то скопировать и запустить. Никаких настроек путей. Либы скопированы в сорцы. И т.д. и и.п.
Люди запускают проект на своем сервере и думают что выложив в опенсорс этим кто-то сможет воспользоваться. Без доделок не смогут. А доделки надо бы апстриму делать.
Разработчик часто и не заинтересован в создании изкоробочных решений в которых "все просто работает". Посмотрите сколько нелепых багов и недоработок оставляют (специально?) чтоб их потом героически решать в рамках "техподдержки".
Да. Хорошо, когда есть aur... Изменил версию в переменной PKGBUILD'а и обновление готово.
> Да. Хорошо, когда есть aur... Изменил версию в переменной PKGBUILD'аХорошо, когда человек может сравнивать -- тогда становится понятно, что так везде.
> и обновление готово.
...после сборки, разумеется.
Только "везде" софт почему-то обновляют далеко не регулярно, т к мейнтейнеру не надо. Всякие тухлые гимпы 2.8.4 валяются, свой пакет хз как куда-то просунуть чтоб выложить на шару всем. Лезть в мейнтейнеры из-за одного пакета неохота.
А в аур любой чувачок с улицы свой типа-пакет сделает и будет сам же себе обновлять приложения на своих компах вместо таскания пакетов на флешке.
И чо?
Повторю:
"Хорошо, когда человек может сравнивать -- тогда становится понятно, что так везде.":)
> А в аур любой чувачок с улицы свой типа-пакет сделает и будет
> сам же себе обновлять приложения на своих компах вместо таскания пакетов
> на флешке.Азохен вей! Таки после таких красивых молодых людей я понимаю зачем пошло выражение "Не было печали, апдейтов накачали".
А прочитать release notes? А проверить совместимость? А просмотреть лог коммитов? Тяп-ляп и готово, да?
Так это арчеводы. О несовместимости они узнают лищь когда продакшн завалился или система при ребуте не взлетела.
А ты, видимо, убунтовод? У вас ведь почти каждый релиз требует переустановки системы с диска. А то, что сборку пакета можно настроить один раз и собирать потом без проблем пару лет - это из области фантастики, да.
>А ты, видимо, убунтовод? У вас ведь почти каждый релиз требует переустановки системы с диска.страшные сказки арчеводов об убунте. Обновлял уже несколько компов. На лоре чувак показательно обновлял с 7.04 помоему, до 12.04. Все через штатный установщик.
Если багфиксы и секьюрити фиксы ломают сборку - то это уже отдельный разговор к разработчику должен быть. в 9 случаях из 10 даже минорные релизы собираются без правки правил сборки пакета, немногим реже без проблем и правок собираются и мажорные релизы.
Так что свой сарказм засунь с свою невежественность. И перед тем как следующий раз пёрнуть, поподдерживай хотя бы полгода хотя бы парочку пакетов программ.
да только разработчики linux kernel об этом не знают. Сколько раз было минорный релиз нес в себе смену API, ABI.
...в ядре. Касающуюся только разработчиков кода, работающего в пространстве ядра.
> да только разработчики linux kernel об этом не знают. Сколько раз было
> минорный релиз нес в себе смену API, ABI.и сколько? перечисли, пожалуйста. а то у меня что-то до сих пор работает ассемблерная софтина, собраная ещё под ядра линейки 1.x.
> А прочитать release notes? А проверить совместимость? А просмотреть лог коммитов? Тяп-ляп
> и готово, да?Вы там в других дистрах по 2 года release notes читаете, а в итоге все работает хуже чем в арче, т к пермаментно тухлое. В арче нормальная практика и после установки пакета что-то настраивать, так что, проблема упирается либо в настройку либо в плохое качество исходной программы (это уже к разработчику)
>А проверить совместимость?Взрослейте уже. Хватит верить в добрых гномиков, магическими тайными ритуалами "тестирующих" пакеты в ынтырпрайз-дистрах. Совместимость с тысячами других пакетов и сотнями тысяч железок никто и никогда не обеспечит, а если вас пытаются уверить в обратном - вас просто разводят на бабки, как последнего лоха.
> Хватит верить в добрых гномиков, магическими тайными ритуалами "тестирующих"
> пакеты в ынтырпрайз-дистрах.Ритуалы не являются тайными. Добро пожаловать на qa.debian.org.
> Совместимость с тысячами других пакетов и сотнями тысяч
> железок никто и никогда не обеспечит, а если вас пытаются уверитьТем не менее, пакеты в дистрибутивах тестируют, глупо это отрицать или игнорировать.
> Забавная ситуация. Но тут уж ничего не поделаешь -- это обратная сторона
> модели репозиториев.В debian такого нет, если некому выпускать обновления - пакет выкидывают из репозитория и предлагают использовать бэкпорты. Даже SeaMonkey недавно выкинули по этому поводу.
В Ubuntu по сути обновления гарантируются только для горстки пакетов, составляющих репозиторий mail. Для основной массы пакетов, которые находятся в universe, никаких гарантий нет и нельзя понять что протухло, а что нет. Поэтому все эти заявления с пятилетней поддержкой Ubuntu лишь мыльный пузырь. Тот же nginx в main совсем недавно попал, что говорить о специализированном софте.
> репозиторий mail.Может, FAIL? :)
main
Лукас Решке мог бы поучаствовать в бэкпортированию исправлений, а позицию "удалите, там неправильно" считаю неконструктивной
Ну вот делать ему нечего. Может ему надо и в RedHat`овские репы посмотреть, какие там версии и бекпортировать? И в Arch? И в SUSE? И бекпортировать-бекпортировать-бекпортировать?
Ой, да ладно, неужели там такие дыры, которые в 2-3 строки не пофиксишь?(Ну а если там та же мажорная версия, то просто надо обновить до последней минорной же...)
Ну вперед, что ждать? Проблема не в том, что сложно, а в том, что некому. Вот возьми и поддерживай пакет, раз это так просто
> Ой, да ладно, неужели там такие дыры, которые в 2-3 строки не
> пофиксишь?Для этого надо уметь 100500 всяких местных идеологически правильных метода сборки пакетов с публикацией, бубликацией и рубликацией.
Я не умею никуя, кроме дебиана и, может быть, слаквари. Да и то, склонен считать, что и этого не умею.
Ну, я и не имею ввиду, что авторы owncloud должны мантейнить пакет в самом дебиане. Я говорю просто о том, что если в принципе НЕТ соответствующей минорной версии с пофикшенными дырами - они её всяко должны выпустить, пронеся туда исправление безопасности...Ну а уж имея деб условно говоря 5.0.1, сделать деб для 5.0.2 любой осилит.
> всяко должны выпустить, пронеся туда исправление безопасности...А они занимали у вас? Или с фига ли они вам должны?
> они её всяко должны выпуститьлюбой каприз за твои деньги.
Политика бэкпорта утопична и ресурсоёмка. А выхлоп мизерный.
Это дебиан-то мизерный?
> Это дебиан-то мизерный?Он про политику держать тухлую мажорную версию и каким-то левым людям сомнительного профессионализма под названием "мейнтейнеры" пытаться искать и переносить пинцетом исправления только безопасности но не багов и недоработок из свежих мажорных версий в тухлую.
Не, редхат конечно может так поддерживать десятилетнее ядро, но во многих других случаях я совсем не уверен. В итоге, софт либо плохо фиксится либо не фиксится вообще.
>> Это дебиан-то мизерный?
> Он про политику держать тухлую мажорную версию и каким-то левым людям сомнительного
> профессионализма под названием "мейнтейнеры"Это ты про политику релизов RH и его сотрудников, прохвессионал?
> Не, редхат конечно может так поддерживать десятилетнее ядро
Ах, другим нельзя. Только нести шапке деньги на блюдечке с голубой каемочкой.
> В итоге, софт либо плохо фиксится либо не фиксится вообще.
Либо ты просто не в теме.
Может ему для всех 9000 тысяч дистрибутивов исправления бэкпортитровать?
Именно! И вот здесь мы приходим к одному важному умозаключению...
...что правильный подход только у арча и генту где либо просто ванильная версия софта без заморочек с бекпортированием, либо собираеш сам ту версию которую считаеш нужной.
Тем не менее в дебиане держат свежие пакеты. Не, Гента хороша (у меня как раз дебиан и гента хз сколько лет) - но говорить, что это правильный подход для продакшна, я бы не стал. Там желательна несколько более предсказуемая конфигурация системы в большинстве случаев. Для дома - годится, но собирать далеко не все готовы.
У него собраны готовые пакеты для кучи дистрибутивов. Даже свои репы есть. Недомейнейнерам влом их класть в репозиторий убунты. Кто виноват?
> Лукас Решке мог бы поучаствовать в бэкпортированию исправленийО, а давайте он ещё для альта будет пакеты собирать. И для слаквари. На всякий.
>> Лукас Решке мог бы поучаствовать в бэкпортированию исправлений
> О, а давайте он ещё для альта будет пакеты собирать.А давайте без давайте. Лицензия у проекта есть? Есть, AGPL. Она нарушена при дистрибуции через бубунту? Нет.
Риторический вопрос: а может не надо ownCloud паразитировать на движении FOSS, если это ПО не является на самом деле свободным (и даже открытым)?
> И для слаквари. На всякий.
Вас же не удивляет что коммерческие пейсатели делают известные телодвижения для обеспечения дистрибуции своих поделий.
Почему в FOSS должно быть иначе? Добрые дяди сделали плохой пакет для бубунту - ну сделай лучше. Тебе-то ведь эти дяди ничего вообще не обязаны. Тем не менее, обеспечили инфраструктуру для поддержки репов, зеркал и проч. Не хочешь чтобы чужие грязные ручки паковали твой безупречный код - публикуй только блобы или иначе явно запрещай дистрибуцию своих поделий в лицензии. Не можете обеспечить security-поддержку стабильных версии - так и напишите в ридми, что ваше поделие - еще надолго альфа-бета, "be warned". И никаких соплей про "поддержание безопасности", которого нет.
Воля ваша, но по-моему Решке сделал "рекламу" своему проекту как образцовый придурок из палаты мер и весов.
Странные люди эти разработчики.
Ну ладно удалять пакет из universe, но почему нельзя было завести акк на ланчпаде и выкладывать свои .deb именно туда, всё равно собирают же пакет ?
Кому нужно - подключит реп и будет регулярно обновлять самый свежак, а так с распространением через собственный сайт проблема обновления пакета ещё более усугубляется, напоминая виндоподход - каждая софтина обновляется отдельно.
Ну да, кроме бубунты же нет дистрибутивов. Да и заняться людям всё-равно больше нечем...
> Ну да, кроме бубунты же нет дистрибутивов. Да и заняться людям всё-равно
> больше нечем...ну, для популярнейшего дистрибутива логично ждать пакеты от самих разрабов.
>> Ну да, кроме бубунты же нет дистрибутивов. Да и заняться людям всё-равно
>> больше нечем...
> ну, для популярнейшего дистрибутива логично ждать пакеты от самих разрабов.Они есть, и репы есть.
http://software.opensuse.org/download/package?project=isv:ow...
>популярнейшего дистрибутиваПо чьей версии?
По версии популярнейшего дистрибутива, вестимо.
> ну, для популярнейшего дистрибутива логично ждать пакеты от самих разрабов.Только если им это надо. А вот это уже полная лотерея.
> Ну да, кроме бубунты же нет дистрибутивов.раз Лукас придалбывается только к бубунте, значит именно так он и думает
> но почему нельзя было завести акк на ланчпаде и выкладывать свои .deb именно туда, всё равно собирают же пакет ?Вечером деньги, утром стулья.
>> но почему нельзя было завести акк на ланчпаде и выкладывать свои .deb именно туда, всё равно собирают же пакет ?
> Вечером деньги, утром стулья.Унылые вбросы. Человек пишет открытый софт бесплатно (условно), но чтоб положить пакетик просит денег. Я не понимаю двойных стандартов.
Автору просто влом делать лишнюю работу для каких-то дистров. Его пакетики собираются автоматом для ряда дистров OBS и его все устраивает.
Так есть же репозиторий, только он не в ланчпаде.
В новости написано как "официальные deb-пакеты, распространяемые с сайта ownCloud", про собственный репозиторий ничего, потому и не стал лезть проверять.
Если конечно собственный репак держат, то и всё равно с этим удалением. Кому нужно - найдёт и подключит, кому нет - даже не заметят.
А, что Ubuntu-ушники приросли в ланчпаду и уже не могут подключить репозиторий, который ведётся в OBS?
> Кому нужно - подключит реп1) чем это отличается от уже имеющейся ситуации?
2) как отмечает User294, эти ваши PPA -- та ещё диверсия для обычного "кому нужно".Речь идёт именно о том, что или пакет, доступный штатно(!) для установки, сопровождается -- или не делайте вид, что он есть. Позиция тяжёлая, но понятная.
> 1) чем это отличается от уже имеющейся ситуации?Разве что тем что дырявые убу
> 2) как отмечает User294, эти ваши PPA -- та ещё диверсия для
> обычного "кому нужно".Ну дык, подключать PPA имеет смысл только если реально надо и если есть доверие разработчикам. Подключать что попало для красоты - это на свой зад. Шансы поиметь проблемы от взлома разработчиков и умыкания ключей или же от злонамеренности действий - увеличиваются. Понятно что на одной стороне весов - жизнь в бункере на километровой глубине - "а вдруг прилетит метеорит?". При этом можно помереть от старости не дождавшись метеорита. С другой стороны, только глупый человек ходит по стройке без каски.
> или не делайте вид, что он есть. Позиция тяжёлая, но понятная.
Да, приветы вашим автосборкам роботами :)
Ну точно так же надо подключать сторонние репы. Смысл тогда в PPA, если сторонняя уже есть?
> Да, приветы вашим автосборкам роботами :)Именно. Правда, это торговля другим риском навроде затрояненого configure.
Миша, вот ты все ерничаешь. А как дела с этим обстоят у альтов? Что, на все пакеты скажем в p7 есть сопровождающие и во все пакеты без исключения вносятся баг-фиксы и секьюрити-фиксы? Или робот по сборке и пакеты от дистров типа Федоры, которые переносятся в Сизиф - наше все?
> Миша, вот ты все ерничаешь. А как дела с этим обстоят у альтов?Плохо. И в среднем хуже, чем у "майнстримных" дистрибутивов -- сейчас нет явного разделения между гарантированно поддерживаемой частью и "как есть", например. После Master 2.4 закончилась публикация рекомендаций по безопасности в классическом виде.
Правда, и принимаемые меры ближе скорее к OpenBSD, чем к федоре.
А людей сейчас не хватает всем, вопрос по обобщению ресурсозатрат и автоматизации рутинной работы стоит тоже везде. Где не стоит -- те или очень нишевые, или ни о чём.
Все понятно. Интересно, а есть дистр, где занимаются людьми? Специально готовят ментейнеров и разрабов, есть четкие полиси и КАЖДЫЙ пакет находится под присмотром и контролем? И пакетов этих больше, чем в репах Убунты?
> Все понятно. Интересно, а есть дистр, где занимаются людьми?Вот этим мне альт и понравился.
> Специально готовят ментейнеров и разрабов, есть четкие полиси и КАЖДЫЙ пакет
> находится под присмотром и контролем? И пакетов этих больше, чем в репах Убунты?А это относится разве что к дебиану, насколько знаю. Но там и бюрократия доведена до маразма, по словам самих DD...
> Вот этим мне альт и понравился.Что, при альте уже КУКСы открыли? :D Слабо в это верится (в то что работников на зряплате обучаете - не сомневаюсь, но ведь это не все мейнтейнеры, так?).
>> Специально готовят ментейнеров и разрабов, есть четкие полиси и КАЖДЫЙ пакет
>> находится под присмотром и контролем? И пакетов этих больше, чем в репах Убунты?
> А это относится разве что к дебиану, насколько знаю.В федоре тоже пакетов порядочно и полиси писать пытаются. Все, в общем-то, хотят как лучше - другое дело как у кого получается. Дьявол, как обычно, в мелочах.
Что касается специальной "готовки" - не думаю что такое есть в природе в к-л проекте (выключая помощь начинающим в тематических рассылках дистрибутива и т.п.). С некоторой натяжкой этим может быть что-то вроде mentors.debian.net.
> Но там и бюрократия доведена до маразма, по словам самих DD...
А вот давайте вы не будете озвучивать анонимные наезды. Ибо обычно выясняется, что информации сто лет в обед (aka год эдак 2005).
> Что, при альте уже КУКСы открыли? :DДавно -- см. архивы рассылок, рассказы с LinuxFest, ну и http://uneex.ru/LecturesCMC вместе с http://uneex.ru/LecturesCMC/PackageMaintaining2013
> С некоторой натяжкой этим может быть что-то вроде mentors.debian.net.
Вопрос именно в том, кто, сколько, почему и зачем возится.
>> Но там и бюрократия доведена до маразма, по словам самих DD...
> А вот давайте вы не будете озвучивать анонимные наезды. Ибо обычно
> выясняется, что информации сто лет в обед (aka год эдак 2005).Извольте: https://github.com/lxde/lxde-qt/issues/299#issuecomment-5927... (причём именно этот комментарий и имел в виду, когда писал -- но он не единичен, да и это как раз предсказуемо было).
> с http://uneex.ru/LecturesCMC/PackageMaintaining2013Конкретно эти лекции - больше похожи на какое-то расплывчатое сяо на тему, чем на практическое введение. Не понял чему собирается научить в "Debian-specific" части человек, который к Debian сейчас отношения не имеет вовсе (поправьте, если я неправ - но у автора в архиве пакетов ровно нуль). Это повар-теоретик? :D
Не умаляя потенциальных достоинств этих курсов, замечу что конкретно специфичные для Debian вещи - хорошо документирует
https://www.debian.org/doc/manuals/developers-reference/>> С некоторой натяжкой этим может быть что-то вроде mentors.debian.net.
> Вопрос именно в том, кто, сколько, почему и зачем возится.Возится тот, у кого есть время на рецензию чужих пакетов.
>>> Но там и бюрократия доведена до маразма, по словам самих DD...
>> А вот давайте вы не будете озвучивать анонимные наезды. Ибо обычно
>> выясняется, что информации сто лет в обед (aka год эдак 2005).
> Извольте: https://github.com/lxde/lxde-qt/issues/299#issuecomment-5927... (причём
> именно этот комментарий и имел в виду, когда писалНу, конкретно афтар этого комментария - DD не является от слова вапще.
По словам самих ДД, нет.~~ Сам ДД.
>> Миша, вот ты все ерничаешь. А как дела с этим обстоят у альтов?
> Плохо. И в среднем хуже, чем у "майнстримных" дистрибутивов -- сейчас
> нет явного разделения между гарантированно поддерживаемой частью и "как есть", например.
> После Master 2.4 закончилась публикация рекомендаций по безопасности в классическом
> виде.
> Правда, и принимаемые меры ближе скорее к OpenBSD, чем к федоре.
> А людей сейчас не хватает всем, вопрос по обобщению ресурсозатрат и автоматизации
> рутинной работы стоит тоже везде. Где не стоит -- те
> или очень нишевые, или ни о чём.Кстати, а почему у альтов после 2.4 дела так скатились? Как и почему вообще дожили до жизни такой?
> Кстати, а почему у альтов после 2.4 дела так скатились?Порядочных людей кинули непорядочные (а в 2009 другие попытались зарейдить), бывает. Жизнь всё равно расставляет по своим местам -- "иных уж нет, а те далече" по обоим случаям.
И уже пять лет вы оплакиваете этот случай. Может надо как-то уже жить дальше?
ownCloud молодцы вообще ребята!
> Для других выпусков утверждается, что удалить пакеты невозможно, так как релизы уже выпущены.Что за глупость? В Debian если некому поддерживать пакет, то пакет удаляют и из прошлых релизов тоже. Это не проблема.
ну, во-первых, в Debian релиз перебивается каждый раз, когда выходит новый субрелиз. т.е., при выходе 7.7 обновления из wheezy-updates, wheezy-proposed-updates переезжают в wheezy, и формируется новый wheezy.в убунте же релиз типа trusty после выхода в день даты - не меняется больше вообще никогда. все обновления уходят тольков trusty-proposed, trusty-security, trusty-updates и trusty-backports. разные выходы версий типа 12.04.4 - не меняют сам релиз, только собирают новые исошники.
а тут, думаю, есть и другие причины - возможно, от этого пакета что-то зависит. но что это нельзя сделать чисто технически - чистая правда :)
Когда я стану президентом — запрещу добавлять вебприложения в репозитории вообще.
Вебприложения это не то, что должно ставиться одной командой из консоли.
> Когда я стану президентом — запрещу добавлять вебприложения в репозитории вообще.
> Вебприложения это не то, что должно ставиться одной командой из консоли.И президентам будешь халтурить на установках веб приложений?
> Вебприложения это не то, что должно ставиться одной командой из консоли.Когда лет десять тому в альте начали обдумывать web application policy, то под изначальный его (утопический на то время) вариант подходили ДВЕ известных софтины -- TYPO3 и ещё что-то. Это те, которые штатно поддерживали r/o код по ссылке и минимальный скелет сайта (или кучки сайтов) с парой симлинков и своим конфигурационным файлом -- тогда пакет можно класть в /usr/share и обновлять, а сайты будут естественным образом пользоваться обновлённым кодом.
Остальные требовалось патчить. Гентушники тогда просто копировали всё, ничтоже сумняшеся. Мы с pilot@ решили, что это слишком низко, в итоге так и не добили.
Это всё к чему: в девяностых считалось нормальным доконфигурировать по месту сишную софтину при установке, поправив пару #define. Десять лет тому это было уже исключением.
Веб-приложения и фреймворки тогда были в ясельной группе, с тех пор количество вменяемых чуть подросло. Но разброд и шатания в веб-разработке больше напоминают жабовую сцену, если так можно выразиться, чем сишную. Похоже, превратившись в субкультуру, копирование (форканье) кусками и целиком вместо повторного использования тут ещё надолго...
PS: интересующимся: оформившиеся с тех пор ключевые слова: webapp policy
О, мне тоже не нравится включение веб-приложений в пакеты.Причём не столько в копировании дело, сколько в том, что у веб-приложений:
а) слишком много разных вариантов расположения, конфигурации, расширения. когда ставишь из дистра - что-то гарантированно окажется захардкожено.
б) мало/нет зависимостей, либо есть собственный пакетный менеджер (cpan, pip и т.п.) - из-за этого использование пакетного менеджера дистрибутива не даёт преимуществ.
в) часто - версии в дистре быстро протухают, а учитывая, что зависимостей мало/нет, проще поставить свежую версию с интернета, чем ждать появления в репах.
Хотел бы добавить: а почему бы не сделать пакет-заглушку, который при установке/обновлении запускал скрипт по скачиванию свежей версии и установке ее поверх предыдущей? Обновился пакет на сайте, поменяли одну цифру в названии пакета в репозитарии, апт скачал новую версию пакета, а последний уже - на оф. сайте. И удобно, и безопасно, и на сопровождение пакета минимум времени уходит.
> Хотел бы добавить: а почему бы не сделать пакет-заглушку, который при установке/обновлении
> запускал скрипт по скачиванию свежей версии и установке ее поверх предыдущей?
> Обновился пакет на сайте, поменяли одну цифру в названии пакета в
> репозитарии, апт скачал новую версию пакета, а последний уже - на
> оф. сайте. И удобно, и безопасно, и на сопровождение пакета минимум
> времени уходит.А потому, что в СПО легких путей никто не ищет. Легкие пути - это происки проприерастов.
>> Хотел бы добавить: а почему бы не сделать пакет-заглушку, который при установке/обновлении
>> запускал скрипт по скачиванию свежей версии и установке ее поверх предыдущей?
>> Обновился пакет на сайте, поменяли одну цифру в названии пакета в
>> репозитарии, апт скачал новую версию пакета, а последний уже - на
>> оф. сайте. И удобно, и безопасно, и на сопровождение пакета минимум
>> времени уходит.
> А потому, что в СПО легких путей никто не ищет. Легкие пути
> - это происки проприерастов.При чем тут легкие пути. Вы, уважаемый, будите на все машины доступ в сеть делать и оплачивать расходы на инет? А без сети эти пакеты-заглушки со скриптами бесполезны.
> б) мало/нет зависимостей, либо есть собственный пакетный менеджер (cpan, pip и т.п.)
> - из-за этого использование пакетного менеджера дистрибутива не даёт преимуществ.Это проблема не веб-приложений, а скриптовых языков с неустоявшимся API/ABI и проблемой базовых версий интерпретаторов. Другое дело, что подавляющее большинство нынешних веб-приложений ровно ими и пользуются.
Отчасти в создании этой проблемы виноваты люди вроде Гвидо, не понимающие толком вопросов поддержки их творчества для применения в реальном мире, а отчасти -- толпа восторженных маководов, сперва сдизайнивших криво гемсы, а затем вынесших раньше срока ворота ruby-1.9... впрочем, толку после драки кулаками махать.
Сейчас тенденция использовать собственные менеджеры зависимостей - (bundler, pip, composer, npm). Да и не только в веб - взять тот же dub.
Что думаете по этому поводу? В том плане, что для разных типов пакетов есть смысл использовать разные системы (на разных уровнях)? Системный пакетный менеджер занимается только системными компонентами, и мейнтейнерам дистрибутивов не нужно париться по поводу всяких веб-приложений - за актуальность их версий отвечают собственные мейнтейнеры или их же разработчики.
dub — идиотизм. для вантузоидов в репозитории исходников кладут dll, которые потом pre-ключами копируются в каталог софтины (см. биндинги к tk, например). я знаю, как это называется, но тут мат стирают.не знаю, что там с маками, а для GNU/Linux всё равно авторы в ридми просят установить нужные пакеты. с таким же успехом дуб можно вообще выкинуть, а в ридми добавить несколько команд клонирования репозиториев с нужными библиотеками. или вообще добавить эти библиотеки как гитовые субмодули.
при этом собрать «комбинашку» из C и D дуб уже не может, например.
дуб не просто бесполезен — он вреден.
> Что думаете по этому поводу? В том плане, что для разных типов
> пакетов есть смысл использовать разные системы (на разных уровнях)?Мысли бродят, ни во что стоящее озвучивания пока не сконденсировались.
Беда в том, что нет слоёв, а есть "независимость" -- т.е. обновляя системную библиотеку, не получается предсказать слом зависевшего от неё модуля для интерпретатора, а ставя новый модуль -- не получается запросить установку системной библиотеки.
Зато не нужно канпелять эти ваши "свежие версии".
Ну вот и выросло поколение, которое уже даже php-приложения компелирует...
> Ну вот и выросло поколение, которое уже даже php-приложения компелирует...Цукерберг тоже компилирует php на своём Фейсбуке. Он даже исходники своего компилятора выложил в опенсорс.
>> Ну вот и выросло поколение, которое уже даже php-приложения компелирует...
> Цукерберг тоже компилирует php на своём Фейсбуке. Он даже исходники своего компилятора
> выложил в опенсорс.Нет. У них был транслятор PHP в C++ (HPHP), но сейчас его заменили на HHVM - по смыслу аналог JVM, только для PHP (ну и их Hack'а), и компиляции там в классическом виде нет, только JIT.
А впрочем кому я объясняю?...
Внезапно - есть не только "PHP-приложения". Есть, к примеру, ПО, состоящее из ядра, написанного на C, и уеб-интерфейса, написанного на PHP. Есть даже (подумать только!) ПО, вообще не содержащее компонентов, написанных на PHP.
Многие юные падаваны безмерно гордятся тем, что выбрали дистрибутив, основанный на бинарных пакетах. Компиляция ПО из исходных кодов они считают занятием недостойным и предосудительным. В их сторону было направлено жало сарказма, который, как оказалось, не все способны понять.
> Компиляция ПО из исходных кодов они считают занятием недостойным и предосудительным.Это было бы странным с учётом того, что бинарные пакеты порождаются, как правило, всё-таки из исходников -- но в чём именно был сарказм, а также сколько жизни Вы лично себе сэкономили пересборкой уже тыщу раз собранного?
а зачем убунтята корячились и собирали свои пакеты, если, как понял из новости, на оф сайте лежат уже собранные дебки разрабами ?
посмотрел и репу можно прописать в сорс лист
Убунтоводы-с
Качать с сайтов дристрибутивы - это пройдите пожлста на Уиндоус.
а вот не буду говорить куда Вам идти
просто спрошу:
- Вы считаете что maintainer, который сопровождает несколько пакетов разбирается досконально в коде программы лучше разработчика ?
- Вы считаете что разработчик программы дурак и не может также опакетить программу, а то и лучше ?
- если брать программы с оф сайта Вы считаете виндовcвэем, но в репе их нет или старые пакеты, то обязательно нужно собирать самому лишь бы не брать с оф сайта ?зачем совершать лишнюю работу с выделение энергии ? тем самым приближая нас к глобальному потеплению =D
Разработчик, как правило, не может опакетить программу в соответствии со всеми нормами, принятыми в дистрибутиве. Вы размер тех же дебиановских полиси видели? А суть дистрибутива - как раз получить систему, играющую по общим правилам.
и шибко это мешает ? из реп разработчика использовать: nginx, vb, zabbix, erlang, x2go, postgres, aurora
> Разработчик, как правило, не может опакетить программу в соответствии со всеми нормами,
> принятыми в дистрибутиве.Вон из профессии.
Понимаю, если нет времени таким заниматься и т.п. Но тогда и людям не надо мешать, паразитируя на FOSS (это типа GPL, но вот этим, энтим и эвтим - паковать нельзя!).
> Вы размер тех же дебиановских полиси видели?
Скромный документик на самом деле. Вот r7rs (который будет про "small" language) - только чуть меньшим числом страниц (оба ~100).
Нет ты!Мейнтейнерствовать можно и дрессированную макаку посадить, так возможно даже лучше, т.к. не будет вахтёрствовать. Это - труд не требующей особой квалификации.
А вот для разработки чего-либо - зайчатки мозга должны быть обязательно. (подчёркиваю - разрабатывать, а не кодировать по указке свыше). Разработчику тупо неинтересно собирать пакеты под десяток дистров, каждый из которых со своими тараканами.
> Мейнтейнерствовать можно и дрессированную макаку посадитьНу тогда и получите дистрибутив для дрессированных макак.
> Мейнтейнерствовать можно и дрессированную макаку посадить, так возможно даже лучше, т.к.
> не будет вахтёрствовать. Это - труд не требующей особой квалификации.Сами вы явно не пробовали это делать нормально. Особенно видя иногда в камментах лучи добра именно мэйнтейнерам, сломавшим то или сё.
во первых: пакеты
во вторых: "дристрибутив" - и есть виндовс
Качать с сайтов разработчиков бинарники и/или исходники некоторых приложений (и сабжа в том числе), а не ставить их из репозиториев - как раз самый правильный подход в силу того, что в репах Ubuntu эти приложения могут оказаться весьма устаревшими (сабж - пример, а также еще ряд корпоративных приложений) и к тому же неполными (практически все средства разработки).
> Качать с сайтов дристрибутивы - это пройдите пожлста на Уиндоус.Что-то не помню чтобы MS дистрибутивы стремился на сайт выкладывать. Самый максимум - бетаверсии, с встроенным кейлоггером.
В корпоративном разделе MS лежат все купленные дистрибутивы.
Зачем вообще делать пакет для PHP движка, и у него нет внутреннего механизма обновления?
> Зачем вообще делать пакет для PHP движка#41
> #41Пытаетесь сорвать ему стэк? :)
Сторонний софт в репах дистра вообще не нужен, там должны быть только базовые пакеты системы. Мне больше нравится принцип реп 0install.Кстати, то же было и с TOR, разработчики попросили его убрать из реп по такой же причине. И его таки не было в каких-то версиях Убунты, но потом опять появился.
> Сторонний софт в репах дистра вообще не нужен, там должны быть только
> базовые пакеты системы. Мне больше нравится принцип реп 0install.Что будем делать с библиотеками?
>> Сторонний софт в репах дистра вообще не нужен, там должны быть только
>> базовые пакеты системы. Мне больше нравится принцип реп 0install.
> Что будем делать с библиотеками?То же самое что и с программами.
Все правильно сделали. Иначе есть большой риск, что уязвимые версии начнут массово ломать и у ownCloud сложится репутация решета.
Есть уже хороший пример PulseAudio, когда значительная часть негатива относительно этого проекта сформировалась из-за того, как это внедрялось в убунте.
Только PulseAudio продолжает кряхтеть и сейчас у меня в федоре и у знакомого на FreeBSD.
ccылки на багрепорты пожалуйста.
Давно уже не испытываю проблем с PulseAudio.
Вообще никогда и никаких проблем со звуком под Linux не испытывал, хотя прошёл OSS, Alsa, Pulse, в Slackware, SuSE, Mandrake, Ubuntu, Arch и на самых разных компах со звуковухами от ISA-шных OPTi и PCI-ных SoundBlaster до всевозможных встроенных. Но это не факт, что у всех так - мне, вот, не везёт с видяхами, кому-то не везёт со звуком.
> Есть уже хороший пример PulseAudio, когда значительная часть негатива относительно этого
> проекта сформировалась из-за того, как это внедрялось в убунте.Угу. Криворукие пейсатели этой дряни - непричем.
Примерно то, о чем я и говорил :)
Нет, ты говорил о паранойе. По примеру системде, если быть последовательным, арч, Фёдора, больше всех дискредитируют СПО, т.к. включают для широкого круга ещё сырыми и недоделанными.
А что, в этих ваших убунтах нет аналога FreeBSD'шного pkg audit, который содержит базу уязвимостей, показывает проблемы с установленными пакетами и не даёт устанавливать новые уязвимые?
Круто придумано - вычерпывать из системы г-но лоханкой, а когда приспичило - "извините, унитаз не работает".
owncloud сейчас переживает период "давайте все перепишем!".
В июне-мае вышла 6 версия.
А августе уже 7 версия.
В git сейчас проскакивают теги 8 версии.
Им уже физически трудно бекпортировать что-то в 4 и 5 версию, из за того, что уже успели все по два раза переписать.
Имхо, могли бы не бекпортировать, а положить новую версию в новую репу.
А в старые репы выкинуть обновление, которое выдаст админу сообщение, что надо обновляться руками.
Это делается один раз.
А чем не угодил openSUSE Build Service настраиваешь apt и всегда свежие пакеты?
ну раз у них есть свой репозиторий, то бубунте надо было не удалять пакет, а сделать пакет подключающий их репозиторий
Могли бы сами почесаться настроить формирование пакетов для одного из самых популярных дистров.
> Могли бы сами почесаться настроить формирование пакетов для одного из самых популярных
> дистров.плати — будут делать.
Самый популярный дистр - windows. Всё остальное должно само чесаться.
Опа, а тут-то: http://distrowatch.com/ и не слыхали о таком дистрибутиве.
Canonical обязана сделать форк в такой ситуации. :)
Я не понял их истерики. Они сами же собирают деб пакеты и выкладывают где-то там у себя. При этом они считают, что им не надо становиться маейнтейнерами, типа не их проблема. Я бы понял, если бы они пакеты не собирали, но сложно что ли отдать свои пакеты и записаться мейнтейнерами? Может, конечно, не дочитал.
Правильно наехали на каноникал, нечего держать старье в репозиториях! Обещают изменить подход к обновлениям софта, если не ошибаюсь, с версии 15.10-16.04... Где не будут для обновлений приложений ждать релиза дистрибутива, а гачить обновления ПО сразу в репозиторий.