LINUX.ORG.RU
ФорумTalks

Установка программ одним кликом появилась в Ubuntu 13.10

 ,


0

2

Несколько месяцев назад, Canonical анонсировала новый упрощенный формат пакета «Click package», нацеленный в первую очередь на мобильные платформы под управлением Ubuntu Touch.

Click package не замена DEB пакетам, а создан как дополнительный формат. Сегодня Click package 0.1.2 появился в секции universe Ubuntu 13.10 Saucy Salamander.

Судя по документации, Click package ориентирован в первую очередь на автономные приложения сторонних разработчиков. В будущем, разработчики смогут легко заливать свои программы в автоматическую систему AppDevUploadProcess, чья задача упростить попадание в репозитории Убунту последних версий сторонних программ.

Софт из Click package будет работать в специальной песочнице, чтобы снизить потенциальный риск вредоносного воздействия.

Заявленные характеристики:

  • расширение файлов .click.
  • для установки можно использовать dpkg, хотя это не поощряется и не рекомендуется.
  • каждый click пакет ставится в свой каталог.
  • скрипты внутри запрещены (за парой исключений).

Источник: http://vasilisc.com/click-package-ubuntu-13-10

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

http://fxr.watson.org/fxr/source/bsd/?v=xnu-2050.18.24

вот, ссылка на исходники BSD части XNU, там можно посмотреть BSD шные копирайты в файлах, например в NFS. Код конечно уже модифицирован относительно оригинального BSD.

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

А вот я не понимаю почему такой срач идет из-за двух абсолютно друг друга дополняющих систем, заточенных под абсолютно разные юзкейсы. click это система даже не для всех ISV. Серьезным ISV как раз удобнее держать несколько своих репозиториев - под rhel & debian. А вот мелким ISV как раз удобнее чтото вроде click

Единственное, что технически не дает (ИМХО) click стать общим форматом для крупной и мелкой рыбы - это отсуствие зависимостей между пакетами.

Ты закатываешь в один пакет свое проприетарное приложение именно потому что оно состоит не из «независимых компонент»

Я думаю, что мне лучше знать.

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

Еще раз - речь не о зависимостях на системные компоненты, а о зависмостях между click-паетами одного вендора.

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

Загугли

Читал и полностью согласен.

Выход один - самому стать апстримом. Я один не потяну - фэйл очевиден.

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

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

дальше продолжать?

Да. Значит Raspberry Pi работает вообще без пакета с ядром или может всё таки там есть пакет с патченным ядром?

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

Ну не нужны они, зависимости между click пакетами.

Тебе лично - не нужны, мне - нужны.

Взять тот же хром

Ты пакаджер Хрома?

всякие сапры с офисами будет легче распространять одним пакетом

Может, ты пакаджер офиса или сапра? А то MS распространяет офис в виде нескольких пакетов.

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

вообще без пакета с ядром

да, и не только оно, все ARM/MIPS железки, которые попадали в мои руки

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

а теперь загрузи свой арм и покажи dpkg -l | grep kernel-image

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

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

Тебе лично - не нужны, мне - нужны.

Мы возвращаемся в самое начало, опять про юзкейсы. Так зачем нужны?

А то MS распространяет офис в виде нескольких пакетов.

Да ладно! Я тут вижу офис только в одном пакете: office_bus_enu_14.0.0_100825.3_ship_volume_build.dmg

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

Мы возвращаемся в самое начало, опять про юзкейсы. Так зачем нужны?

Я уже описал.

А то MS распространяет офис в виде нескольких пакетов.

Да ладно!

Что, больше не распространяет? Раньше я точно мог поставить Ворд и не ставить Эксель.

Я тут вижу офис только в одном пакете: office_bus_enu_14.0.0_100825.3_ship_volume_build.dmg

ГейОС не пример.

tailgunner ★★★★★
()

Вроде как хорошо сделали. Главное, что не тронули deb-пакеты. А так - глядишь, и больше полезных, но мелких поделок появится.

cdshines ★★★★★
()

Всё больше похоже на мастдайку. В какой ещё ОС устанавливают ПО при помощи мыши? Есть в этом что-то неправильное...

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

суть в том, что в андроиде помимо apk нет пакетного менеджера (что, кстати, плохо, ИМХО)

Ну и? гнулинукс более универсальная система чем андроид. Это по сути конструктор для сборки и тестирования систем. Все это гугл делает внутри себя - в результате соотвествующий инструментарий для распределенной разработки такой системы ненужен.

deb может быть как с зависимостями внутри, так и без них извне (не считая, разве что, libc)

Давайте не про теорию а про практику. В практике деб-репозиторий для распостранения isv софта (то есть то для чего click) это нечто перелинкованное зависимостями внутри и извне. Зависимости и правила сборки.

Но если чо, click это и есть deb. click от deb отличается ограничениями наложенными на контент.

в первом приближении:

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

Я понимаю что «линупсоедов» бесит до стучания башкой в стену банальное переименование расширения с deb на click, у них глаза выпучиваются и они впадают в паадучую от одного слова маркетинг(которые они к этому переименованию пытаются присобачить) - но к click это имеет мало отношения.

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

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

спасибо.
но я думал, ты про hfs говорил.

HFS самодельная, но реализована поверх BSDшной VFS.

Если мне не изменяет память, до 10.6 поддерживалась BSDшная UFS.

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

Вот почему у 99.9999% пакетов нет в зависимостях ядра linux?

А что эти 99% пакетов зовут ядерные функции? А не какой нить libstdc++ или libc?

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

Я уже описал.

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

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

Раньше я точно мог поставить Ворд и не ставить Эксель.

А это разве не бинарный инсталлятор? Ну, там галочки ставишь, а потом жмёшь install :) Знаешь, а это ведь не куча разных пакетов и даже зависимостями там не пахнет... В любом случае, для таких вендузятников и в линуксе остались всякие инсталляторы.

ГейОС не пример.

Зато венда пример, ага.

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

Вот почему у 99.9999% пакетов нет в зависимостях ядра linux?

А что эти 99% пакетов зовут ядерные функции? А не какой нить libstdc++ или libc?

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

это не пакет, а образ файловой системы

Так-так-так... А как тогда в такой системе поставить приложение, зависимостей же нет :) Ой, наверное под такую систему надо будет переделывать пакет... А может быть даже использовать click, божемоймывсеумрём!!!

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

ты сделал всё, что угодно - поистерил, построил из себя ребёнка, даже топнул ножкой и заявил, что «так будет лучше

Что, не хватает тебя больше, чем на пару постов во вменяемом тоне?

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

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

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

А что эти 99% пакетов зовут ядерные функции? А не какой нить libstdc++ или libc?

У многих приложений даже libc в зависимостях не прописан. Разработчики как бы верят, что уже всё установлено :) Наивные такие, правда?

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

«Операционные системы» Appl^Wгруши

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

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

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

Неpower юзер должен использовать то, что ему дает power-майнтейнер.

В реальном мире не бывает так, чтобы все юзеры были не-power, а все майнтейнеры — power. Я уж не говорю о том, что это весьма субъективные вещи, например даже очень хорошо знакомый с чем-то другим мейнтейнер не сможет собрать толком программу на Qt, если не знает возможностей Qt — обязательно же что-то пропустит, и пропускают.

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

Что, не хватает тебя больше, чем на пару постов во вменяемом тоне?

Да я вообще белый и пушистый и всего лишь перечислил всё, что ты тут наделал во время разговора, комментарии на виду :)

Обоснуй свой ответ.

Для меня программный комплекс - это библиотеки, ресурсы и куча бинарников. В данном примере будем считать, что разработчик наркоман и не хочет пользоваться системными библиотеками, а без libastral.so его приложение вообще работать не будет. Другими словами, у нас уже есть общие компоненты, которые хотят использовать разные бинарники. Допустим, что это совсем разные бинарники - например, какой-нибудь сервер, клиент и конфигуратор и все будут выполняться на разных системах - на сервере, у менеджера и у программиста. Тогда будет 4 click пакета program_comon.click, program_server.click, program_client.click и program_config.click. Если же приложения невозможно использовать на разных системах или приложения отличаются только бинарниками, которые весят крайне мало и основной размер занимают общие ресурсы, то легче сделать один click пакет. Если же общих ресурсов крайне мало, а бинарники отличаются очень сильно или у всех свои ресурсы, то легче сделать 3 click пакета, засунув в каждый из них свои библиотеки. Если же в такой программной комплекс, который засунули в один click пакет, нужно подключить дополнительный компонент, который, например, продаётся отдельно, то этот компонент можно отдельно упаковать в click пакет (в качестве примера можно взять какой-нибудь рендер для пакета моделирования - получается всего 2 пакета).

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

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

Да я вообще белый и пушистый и всего лишь перечислил всё, что ты тут наделал во время разговора, комментарии на виду :)

Это да. Каждый, кто даст себе труд прочитать их, решит для себя.

4 click пакета program_comon.click, program_server.click, program_client.click и program_config.click

Замечательно. Итак, зависит ли program_server.click от program_common.click? Если да, как именно это указывается? Если нет, то почему?

Теперь я внимательно слушаю, почему пользователь лора считает себя умнее гугла, эппла и марка вместе взятых :)

Найди этого пользователя и спроси его.

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

Все это гугл делает внутри себя

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

В практике деб-репозиторий для распостранения isv софта (то есть то для чего click) это нечто перелинкованное зависимостями внутри и извне. Зависимости и правила сборки.

ну-ну, посмотри на chrome-овский репозиторий, много там зависимостей и правил сборок?

они впадают в паадучую от одного слова маркетинг(которые они к этому переименованию пытаются присобачить)

мне кажется, или ты первый употребил это слово?

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

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

deb по сути не предназначен для распространения вне репозитория

смотрим на skype

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

А кому он нужен полуброшенный?

Пока нет адекватных замен - мне. KWin до сих пор не дотягивает до кастомизабельности compiz. Weston теоретически может его переплюнуть, но compiz работает уже здесь и сейчас. Я говорю о старой ветке, конечно, 0.9.* - это фэйл по многим статьям. Хотя некоторые баги там и починены, общее состоянии ужасно.

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

Значит Raspberry Pi работает вообще без пакета с ядром или может всё таки там есть пакет с патченным ядром?

В Raspbian скорее всего кастомный пакет с ядром. Но ставить зависимость от пакета ядра Linux некорректно(если только это не Linux-only вещь). Пример - тот же Debian/kFreeBSD.

Другое дело, если есть некий метапакет «ядро». Но тогда от него будут зависеть все остальные пакеты, что как бы фэйл. Практически тоже самое и с libc.

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

Единственное, что технически не дает (ИМХО) click стать общим форматом для крупной и мелкой рыбы - это отсуствие зависимостей между пакетами.

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

Ты закатываешь в один пакет свое проприетарное приложение именно потому что оно состоит не из «независимых компонент»

Я думаю, что мне лучше знать.

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

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

Еще раз - речь не о зависимостях на системные компоненты, а о зависмостях между click-паетами одного вендора.

Я тебя понял. Я говорил про то что никакой реальной независимости между отдельными пакетами в любом репозитории нету, в том числе и в репозитории вендорском. Пакет в репозитории не является независимой единицей, в отличие от репозитория целиком.
И в случае энд-юзера выставлять свой софт в качестве кучи пакетов - это делать «кишки наружу». Эндюзеру эти кишки ненужны. Для него вся твоя куча пакетов - одна логистическая единица, а то что ни там обновляются по отдельности ему плевать. Для него удобнее не разбираться в том что и как у тебя там обновляется, а нажать на кнопку «поставить апдейт номер 100500»

А вот если мы говорим об админе сложного софта, который ведет некую сложную инсталляцию, то таки да, ему с зависимостями удобно. Но это совсем другая задача. Почему бы тогда ему просто не использовать уже готовый apt-get (yum) и вендорский репозиторий? То есть ты зачем то пытаешься прикрутить к специально упрощенной системе сложность, которую от нее откручивали специально?

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

Хе-хе, а чем это репозиторий click пакетов принципиально отличается от репозитория deb пакетов? :)

В песочнице выполняется.
Lordwind наверное по вирусам соскучился и поэтому ему это не нравится.

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

Еще раз - речь не о зависимостях на системные компоненты, а о зависмостях между click-паетами одного вендора.

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

Т.е. в вашем случае нужно паковать в Deb или предоставлять общие зависимости отдельным Deb пакетом а приложения click-пакетом

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

Итак, зависит ли program_server.click от program_common.click

Если сначала установить program_common.click, то ничего не произойдёт - на винте просто будет папка с ресурсами. Если сначала установить program_server.click, то будет ошибка и грамотный программист добавит уведомление «отсутствует program_common.click». Более того, сейчас ситуация хуже - так как зависимости «учитываются», то ту же 1с нужно устанавливать в определённом порядке - купленное приложение, состоящее из нескольких пакетов есть только на диске и отсутствуют в репозитории, а это значит, что при установке пакета с неудовлетворёнными зависимостями просто будет вылазить ошибка.

Следовательно, в идеале лучше сделать один click пакет (как делают те же microsoft или adobe со своими приложениями под мак), либо подымать свой репозиторий, как это сделали разработчики dr.web for linux.

Найди этого пользователя и спроси его.

Ха-хахаха-ха! Прекрати, человек-анекдот

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

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

Я ее не игнорирую. Я знаю ее изнутри и снаружи.

А вот если мы говорим об админе сложного софта, который ведет некую сложную инсталляцию, то таки да, ему с зависимостями удобно. Но это совсем другая задача. Почему бы тогда ему просто не использовать уже готовый apt-get (yum) и вендорский репозиторий?

А по-моему, задача та же самая. Нужно просто разрешить использовать apt-get с click-пакетами, но для этого в них должны быть зависимости.

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

Я считаю, что систему сделали бессмысленно простой. Если Ubuntu App Store нужны имено пакеты без зависимостей, пусть это проверяют при приемке в App Store.

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

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

Для игрушек и многих прикладных свистоперделок это далеко не так.

Неpower юзер должен использовать то, что ему дает power-майнтейнер.

Это в теории. Для этого power-майнтейнер должен не выкладывать «универсальный федора линупс 100500», а делать законченное юзерское решение - чего на десктопе нет и что-то мешает этому появится. И да, таких решений должно быть овердофига - сколько есть юзеров, фактически.

Именно на таких неpower юзеров вся технология репозиториев и рассчитана.

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

А вот локальная установка нужнадля игр и практически только для них

Для любых прикладных свистоперделок. Игры естественно included. Вот например, хочу поставить свистоперделку «будильник». И что, ждать пока эту ненужную шутку кто-то засунет в репозхиторий? Или самому этим заниматся? Это бред. Пусть эту свистоперделку суют в apk/click и я ее поставлю в один клик.

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

Итак, зависит ли program_server.click от program_common.click

Если сначала установить program_common.click,

Если тебе что-то непонятно в моих вопросах, не стесняйся переспросить.

Найди этого пользователя и спроси его.

Ха-хахаха-ха!

Если ты считаешь меня умнее гугла и прочих, это твоя личная проблема.

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

SELinux научился отслеживать bundled libs? o_O

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

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

Еще раз - речь не о зависимостях на системные компоненты, а о зависмостях между click-паетами одного вендора.

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

Если в одну песочницу нельзя поставить 2 пакета - это еще одно исскуственное ограничение; и я говорю о зависмостях в пределах одной песочницы.

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

Они же не удаляют классический подход. В конце-концов останутся и другие дистрибутивы. В чем проблема?

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

общее состоянии ужасно

Ладно, не важно. Просто жаль, что сообщество не может допилить его до адекватного состояния. А Canonical не фиксит его, потому что все силы бросили на unity8/mir и это их право.

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

Другое дело, если есть некий метапакет «ядро». Но тогда от него будут зависеть все остальные пакеты, что как бы фэйл. Практически тоже самое и с libc.

Я чуть ранее намекнул, но боюсь, что ещё не все осознали шутку юмора. Любое приложение (разработчик) сможет рассчитывать, что ядро есть, поэтому его нет в зависимостях. Так и пакеты click могут быть уверены в наличии ядра linux, Qt, python, gstreamer и notify-osd.

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

Lordwind наверное по вирусам соскучился и поэтому ему это не нравится.

А кто мешает поднять левый репозиторий с заражёнными пакетами?

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

не стесняйся переспросить.

На этом всё? Я рад, что больше нечего возразить.

это твоя личная проблема.

У меня нет проблем, я несу свет понимания даже человекам-анекдотам :)

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

Я ее не игнорирую. Я знаю ее изнутри и снаружи.

И много ты занимался разработкой софта для которых apk/dmg являются основными? Ты смотришь на все со своей колокольни желчного разработчика аппаратно-программного комплекса где проблем такого характера просто не возникает.

А по-моему, задача та же самая. Нужно просто разрешить использовать apt-get с click-пакетами, но для этого в них должны быть зависимости.

Замечательно. Если раньше у нас был огорожденные внутренности сендбокса, то теперь эти внутренности сендбокса взаимодействует с абсолютно не расчитанным на секурити тонной кода в apt-get'е. Сейчас же есть простой алгоритм который возможно написать максимально секурно.

Я считаю, что систему сделали бессмысленно простой. Если Ubuntu App Store нужны имено пакеты без зависимостей, пусть это проверяют при приемке в App Store.

Нужны не «пакеты без зависимостей» а законченное, простое, минимальное решение.

Более того, подозреваю что можно вызывать apt-get и апдейтать свою инсталляцию внутри сендбокса вручную со своего собственного долбанного репа :D Для тех кто без сложностей не может :D

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