LINUX.ORG.RU

еще один аргумент в пользу юзерского пакетного менеджера (в дополнению к рутовскому)


0

0

1. В КДЕ-шных редакторах (kate, kwrite, kdevelop, предположу что в qt creator) юзаются схемы цветовой подсветки. Так вот, глубоко в настройках имеется кнопочка [download], позволяющая скачать обновления этих схем с сайта. При этом (по крайней мере с первого взгляда) кажется, что это сделано внутри программы, и скрипт, качающий обновления, не запустить по крону; также нельзя зафиксировать список тех языков, обновлять которые не нужно.

Предлагаемое решение: ставить эти схемы как пакеты «от юзера».

2. Иногда приходится иметь разные версии библиотек для разных проектов. Можно было бы собирать эти проекты под разными юзерами, и опять же держать эти библиотеки как пользовательские пакеты.

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

Дискасс.

З.Ы. наличие внутри настроек кнопки [download] — зло. А что кроме юзерских пакетов можно предложить взамен нее?

З.Ы.Ы. запостил это в Development, так как аргументы приводятся от лица девелопера, но не возражаю переносу в другую ветку.

★★★★★

Последнее исправление: www_linux_org_ru (всего исправлений: 4)

> наличие внутри настроек кнопки [download] — зло
Да нет, не такое и зло. Тут эти настройки и выступают в роли пакетного менеджера. Только нигде явно не виден список пакетов.
Про несколько версий одной программы. Это вполне можно реализовать пересборкой пакета со сменой названия. Как сейчас с ядрами. Просто такое пока не особо нужно. Понадобится большому количеству человек - разработчик программы сам будет решать эту проблему

Breton
()

Нужна некое приложение, которое с одной стороны будет поддерживать разнообразные форматы репозиториев (включая, например, мозилловские аддоны, эклипсовские аддоны), с другой будет иметь простое API для интеграции с существующими приложениями, с третьей будет иметь эти самые аддоны для популярных форматов пакетов, включая rpm, deb. Чтобы устанавливая Kate подключались его маленькие репозитории с цветовыми схемами, и работу по установке/удалению/обновлению этих схем выполняло это приложение. Тогда будет счастье. Впрочем та же мозилла кроссплатформенна, а значит должна обеспечивать addon management и под вендой, поэтому тут вопрос тоньше.

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

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

решается написанием (упрощенного) dpkg для работы с каждым типа аддонов

с другой будет иметь простое API для интеграции с существующими приложениями,

это про что? чтобы кнопка download вызывала apt-get update?

с третьей будет иметь эти самые аддоны для популярных форматов пакетов, включая rpm, deb.

ага

Впрочем та же мозилла кроссплатформенна, а значит должна обеспечивать addon management и под вендой, поэтому тут вопрос тоньше.

для юзерских пакетов винда не проблема

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

> Просто такое пока не особо нужно.

И поэтому питонщики свелосипедили себе свой пакетный менеджер, РНР-сты — тоже свой (которые ЕМНИП разрешают зависимости, работают от рута и только со своими пакетами)

www_linux_org_ru ★★★★★
() автор топика

Вспомнил вот еще что: русификация. Она требует прописывание строчек в конфиги *каждого* юзера, и не может быть сделана *общесистемным* пакетом.

Ну и любая аналогичная кастомизация.

www_linux_org_ru ★★★★★
() автор топика

Целиком и полностью согласен. Я считаю, что у пользователя должна быть возможность поставить программу только для себя, не затрагивая при этом остальных пользователей и систему в целом. На данный момент такой возможности нет. Но тут ещё вопрос в том, что у некоторых программ пути до ресурсов, например, жёстко зашиты в бинарники. Так что либо переписывать их, либо делать сорс-базед пакетный менежер. Либо виртуальную файловую систему, которая каждому пользователю будет предоставлять свой /usr :)

Laz ★★★★★
()

А теперь вспомните vim и emacs, и успокойтесь.

ip1981 ☆☆
()

А в чем вопрос? zeroinstall уже есть

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

>решается написанием (упрощенного) dpkg для работы с каждым типа аддонов

написал я вот такую штуку: http://github.com/annulen/avogadro/blob/master/avopkg.in

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

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

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

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

annulen ★★★★★
()

Отдельный пакетный менеджер не нужен, т.к. то, что нужно юзеру 1-2 пакета, которые можно и вручную собрать под себя. Зачем усложнять систему ради 1,5 человека.

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

>configure

make

cp


Это уже не управление пакетами.

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

>installpkg --root /otherroot
В некоторых программах (хорошо, что не во всех) пути к конфигам, ресурсам итд зашиваются в бинарник, да так, что параметрами командной строки правильные пути не указать. В таком случае предложенный вариант работать не будет.

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

> Либо виртуальную файловую систему, которая каждому пользователю будет предоставлять свой /usr :)

Гы, ребята из Bell-labs додумались до этого несколько раньше. В Plan9 и в велосипеде WMII это уже есть. Осталось только использовать этот механизм по назначению.

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

> Отдельный пакетный менеджер не нужен, т.к. то, что нужно юзеру 1-2 пакета, которые можно и вручную собрать под себя. Зачем усложнять систему ради 1,5 человека.

меня совершенно не интересуют «юзерские сборки системных пакетов» (которые вдобавок еще и сопротивляются своими захардкоженными путями :-), я веду речь о тысячах (а у юзера могут быть сотни) устанавливаемых именно в ~/ *by design* файлах.

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

>> Либо виртуальную файловую систему, которая каждому пользователю будет предоставлять свой /usr :)

Гы, ребята из Bell-labs додумались до этого несколько раньше. В Plan9 и в велосипеде WMII это уже есть. Осталось только использовать этот механизм по назначению.

Ну я сопсна с оглядкой на plan9 эту идею и выдвигал :)

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

Вообще говоря, докладчики забывают о зависимостях (реальных, а не пакетных, - *.so.x.y.z), поэтому параллельная система пакетов огребёт кучу проблем. Если очень надо, делайте виртуализацию.

Если надо установить программу себе, это обычно делают компилирование исходников (configure, make, make install). Проблемы с hard-coding решаются патчами (да-да).

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