LINUX.ORG.RU

Вышел PackageKit 1.0 — высокоуровневый интерфейс для пакетных менеджеров

 


0

2

13 сентября вышла новая версия открытого и свободного набора приложений, обеспечивающих высокоуровневый интерфейс для различных пакетных менеджеров. Для межпроцессного взаимодействия и управления правами доступа используются D-Bus и PolicyKit.

Это первая стабильная версия, выпущенная за 7 лет разработки, в течение которых поступило 11697 коммитов от 284 разработчиков.

Основные изменения:

  • Теперь для оффлайн-обновления (способ обновления важных системных компонентов в начале загрузки системы, продвигаемый разработчиками проектов GNOME, PackageKit и systemd) вместо вспомогательных модулей pkexec используется интерфейс D-Bus;
  • Из-за общей забагованности и падучести плагинов удалены все плагины (кроме бэкендов для пакетных менеджеров), прекращена поддержка API для них. Функции плагинов будут постепенно влиты в основную кодовую базу;
  • Удалена поддержка бэкендов для пакетных менеджеров conary, opkg, smart, yum. Они не работали уже года два, а желающих их поддерживать не нашлось;
  • Обновлены бэкенды для пакетных менеджеров alpm, aptcc, hif, zypp. Включена поддержка новейших возможностей, появившихся в этих менеджерах.

Прочие новые возможности:

  • В packagekit-direct добавлена команда repo-set-data;
  • Появился несложный скрипт для создания оффлайн-метаданных;
  • Добавлены функции pk_backend_job_get_cancellable(), pk_backend_job_is_cancelled(), pk_backend_set_user_data(), pk_offline_get_prepared_sack(), ранее используемые плагином systemd-updates;
  • Удалена поддержка pk-debuginfo-install;
  • Удалена поддержка дистрибутивов, не содержащих /etc/os-release (файл с информацией о выпуске дистрибутива, продвигаемый командой systemd в качестве единого стандарта);
  • Удалена поддержка опции --enable-systemd-updates;
  • Удалён функционал events/pre-transaction.d;
  • Удалены некоторые опции из конфигурационного файла.

Исправленные ошибки:

  • Для потоковых бэкендов автоматически выполняется pk_backend_job_finished();
  • Теперь по умолчанию демон не завершает свою работу при простое;
  • Налажена сломанная ранее сборка с поддержкой ConnMan;
  • Исправлено создание packagekit-offline-update.service;
  • Увеличены значения, применяемые по умолчанию для лимитов транзакций;
  • При выборе между npapi-sdk и mozilla-plugins предпочтение отдаётся первому;
  • При запуске демона обновляется состояние NetworkManager.

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

anonymous

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

Когда эти чудаки из федорки передут на деб? Задолбали плодить несовместимые стандарты.

anonymous
()

13 сентября вышла
Released: 2014-09-12

JK
()

Из-за общей забагованности и падучести плагинов удалены все плагины

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

X10Dead ★★★★★
()

Интересная штука! Мож, мне даже не придется плодить сущности у пары моих прог...

DeadEye ★★★★★
()

Надо же, этот велосипед дожил до релиза 1.0.

Удалена поддержка дистрибутивов, не содержащих /etc/os-release (файл с информацией о выпуске дистрибутива, продвигаемый командой systemd в качестве единого стандарта);

В этом месте я взоржал.

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

Да нафиг он нужен.

pkgsrc прекрасен сам по себе, без таких свистоперделок. :)

Deleted
()

Давно пора сделать один интерфейс для всех.

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

Походу это глюкавое поделие готовится влиться в system-d

Пусть сначала ddd осилят.

anonymous
()

Удалена поддержка бэкендов для пакетных менеджеров conary, opkg, smart, yum. Они не работали уже года два, а желающих их поддерживать не нашлось;

Они решили его убить? Или таким образом хотят помошников заполучить. Типа: помогите или застрелюсь?

anonymous
()

Из-за общей забагованности и падучести плагинов удалены все плагины (кроме бэкендов для пакетных менеджеров), прекращена поддержка API для них. Функции плагинов будут постепенно влиты в основную кодовую базу;

Печально все это, очень печально. Еще одно монолитное «» делают?

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

Печально все это, очень печально. Еще одно монолитное «» делают?

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

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

А я - заплакал. Системд головного мозга. Расстрелять.

anonymous
()

И когда уже управление пакетами перенесут в systemd и не будет этого зоопарка...

anonymous
()

Не нужно. Лишний слой абстракции, который в куче дистрибутивов нафиг не нужен. Да ещё и понапихали туда слишком много.

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

Но зачем? Есть же Ubuntu Software Center.

Открою тебе страшную тайну - не у все эта ваша убунта.

mbivanyuk ★★★★★
()

Удалена
Удалена
Удалена
Удалён
Удалена

Воу, воу, воу! Полегче!

Удалена поддержка бэкендов для пакетных менеджеров... yum, ...

А вот это зря.

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

И когда уже управление пакетами перенесут в systemd

Это пять!

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

the file format is the baseline package format of the Linux Standard Base.

Где-то тут была ветка года с два назад, что в LSB входит rpm третьей версии, несовместимый с используемыми сейчас в rpm-дистрибутивах четвёртой. Так что на тот момент единственным LSB-совместимым дистрибутивом был как раз дебиан.

Так что:

Когда эти чудаки из RH/Fedora/CentOS передут на рпм третьей версии? Задолбали плодить несовместимые стандарты.

anonymous
()

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

anonymous
()

А что с libalpm (pacman), кто знает? Бэкенд для него совсем-совсем не собираются пилить, и в арче так и будет 0.7.6, пока окончательно не сломается?

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

Зачем оно, когда есть Pacman, самый лучший менеджер всех времен и народов?

оно уже научилось пустые каталоги не удалять, когда не просят?

anonymous
()

я чего-то не понял - это типа менеджер для пакетных менеджеров? Еще пара менеджеров - и натуральный отдел продаж получится

upcFrost ★★★★★
()

Блджад.

Почему бы им всем не договориться и не оставить один формат пакетов? cpio.gz, как в грёбаном тиникоре, например (только там он TCZ называется). Каждый пакет - срез ФС, который монтируется на лету. Универсально, невелосипедно, стильно, модно, молодёжно. Если этот старпёр Шингльдекер что-то будет вякать, то cpio.gz и до него использовали. Мейнтейнеры, ау!

border-radius
()
Ответ на: Блджад. от border-radius

Почему бы им всем не договориться и не оставить один формат пакетов? cpio.gz

Формат в смысле «как распаковать» — проблема давно решённая. Есть alien, который всё успешно распаковывает. А вот где в этом cpio будет лежать debian/rules, как он будет называться и на какие утилиты в системе может рассчитывать — это уже в каждом дистрибутиве уникально, Даже rpm между altlinux и centos очень плохо переносится.

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

Ну так неужели действительно сложно договориться о едином месте хранения информации о зависимостях, пре-инсталл, пост-инсталл задач и других метаданных? Вплоть до того, что в монтируемом пакете эта инфа будет храниться в каких-нибудь /usr/share/pkginfo/dep_rules/<package_name>/, /usr/share/pkginfo/premount_rules/<package_name>/, /usr/share/pkginfo/postmount_rules/<package_name>/ и т.п., а утилиты подключения/отключения пакетов будут следить за изменениями в этих каталогах и выполнять соответствующие правила.

border-radius
()

еще один никому не нужный стандарт в зоопарке никому не нужных стандартов?

если оно вольется в системд, снесу последний к чертям собачьим!

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

the file format is the baseline package format of the Linux Standard Base.

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

anonymous
()

Удалена поддержка бэкендов для пакетных менеджеров conary, opkg, smart, yum. Они не работали уже года два, а желающих их поддерживать не нашлось;

желающих их поддерживать не нашлось;

Ибо PackageKit - нинууууужнажы!

Indexator ★★★
()

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

Vier_E ★★★
()
Ответ на: комментарий от border-radius

Вы задаете неправильные вопросы в неправильном месте. По факту, множество не самых глупых людей за 20 (а то и 30 с учетом BSD) лет не сумели договориться. По системд и то больший консенсус - сейчас вот у сына на ноуте ubuntu 14.10, там даже journalctl можно запустить (правда, все логи по-прежнему, видимо, не через journald). Так что, единственная /надежда/ на унификацию системы пакетирования - это, как ни смешно, передача её под руководство Поттеринга или кого-то еще со сходными методами работы и влиянием. Ну и с тоннами кирпичей, куда в таком деле без них.

AlexM ★★★★★
()
Ответ на: комментарий от border-radius

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

Так в этом и проблема. По большому счёту только эти вещи и отличают дистрибутивы.

1) о зависимостях

Нет единого стандарта наименования пакета (libc, libc6, glibc, glibc-2.19, ...). Нет единого мнения о том, что считать пакетом (glibc или glibc + glibc-dev + glibc-bin + glibc-dbg + ...). Нет единого мнения, что считать зависимостью: xterm должен зависеть от X сервера? База данных от MTA? Emacs от GTK?

2) пре-инсталл, пост-инсталл задач

В каждом дистрибутиве свои хелперы и свои места для настроек. Поэтому пре-инсталл в SuSE — записать в rc.conf, в debian — update-alternatives и dh_*, ...

3) других метаданных

Должны ли контрольные суммы файлов быть в пакете, рассчитываться, или в отдельном файле. Должен ли в пакете хранится url источника. Как должны называться файлы с метаданными... тут вон с /etc/*release* всё никак договориться не могли.

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

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

border-radius
()
Ответ на: комментарий от border-radius

Баннеры а-ля тех, что в Юнити - не самое плохое, что может случиться при унификации. Целый системд тому примером ;)

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