Универсальная пакетная система.

Нет, конечно. Самое близкое aur из арча.

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

yaourt

Почему «конечно»?

В смысле yaourt для разруливания зависимостей.

Нет, конечно.

ZeroInstall.

Скачал программу откуда-нибудь в виде левого пакета: rpm, deb, или другой. Щёлкаешь по нему или запускаешь из консоли, он запрашивает зависимости, пакетный менеджер их устанавливает, и после этого сам пакет устанавливается.

Хотя ебилды тоже вроде могут

Ты говоришь про установку не из реп, т.е. установку из сырцов? Если так, то как пакетный менеджер должен парсить риадми-файл в котором прописаны зависимости пакета?

зависимости по требованию стороннего пакета? То есть который не в репозитории.

dpkg -i foreign-package.deb # ставится пакет и ругается на отсутствие libzzz, которая есть в репозитории
apt-get -f install # libzzz скачивается из репозитория, foreign-package.deb настраивается

Хм, интересно. Я опять все прослоупочил, почитаю. Но в любом случае это пока что сырое еще.

Не понял. Т.е. зависимости устанавливаются в runtime, а не статически? Тогда полноценной системы нет, т.к. требуется поддержка со стороны пакета, а единого API нет. Что-то подобное реализовано в Fedora с PackageKit - тот просил даже установку шрифтов при открытии диалога, в котором он требовался.

Таки да: ZeroInstall. Каждый пакет имеет уникальный url, разрешщение зависимостей происходит по url-ам.

Но с «rpm, deb, или другой» это, понятное дело, не работает.

Ты говоришь про установку не из реп, т.е. установку из сырцов?

Из сырцов, из пакетов.

Если так, то как пакетный менеджер должен парсить риадми-файл в котором прописаны зависимости пакета?

Ладно, пускай только rpm и deb.

Про apt-get/aptitude -f уже сказали.

Тогда мне нужен не ZeroInstall. Разве трудно научить пакетный менеджер выуживать прописанные зависимости из пакетов?

Стоп-стоп-стоп. Установка пакетов в родном формате и так производится по зависимостям, с автоматическим разрешением оных из репозитория.

Не понятно, чего ты хочешь добиться.

Не понятно, чего ты хочешь добиться.

Чтобы не только в родном формате.

А вообще это невозможно, потому что деление на пакеты во многом условное. В разных дистрибутивах оно не совпадает.

Ладно, пускай только rpm и deb.

Тогда zypper, apt-get и вообще что угодно, пакет скачанный тобой из интернета ничем не отличается от пакета, скачанного пакетным менеджером из реп, кроме отсутствием возможности централизованного обновления.

А если из сырцов, то посмотри как огромен aur, yaourt подтягивает зависимости даже из него, компилируя их во время установки искомого пакета.

Чтобы не только в родном формате.

http://en.wikipedia.org/wiki/AppStream

«major GNU/Linux vendors (i.e. Red Hat, Canonical, Novell/SUSE, Debian, Mandriva, etc.)» велосипедят универсальную установочную систему.

Но лично моё мнение: этот монстр развалится под собственной тяжестью.

А вообще это невозможно, потому что деление на пакеты во многом условное.

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

Или найти, но не ту, что не лучше.

в каждом дистре названия пакетов отличаются и пакетный менеджер может просто не найти зависимость

И ведь в самом деле.

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

Предлагаю создать общую базу всех опен(а может даже и неопен)сорных пакетов с возможностью разрешения зависмостей по UUID

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

А что тебе надо-то? Зачем городить такие велосипеды? Собирай руками и зависимости и пакеты или ставь из реп. Я в лучшие годы кеды на слаку собирал из сырцов со всеми зависимостями.

Поддерживать такой скрипт будет слишком трудно. Лучше иметь онлайн-базу

Предлагаю создать общую базу всех опен(а может даже и неопен)сорных пакетов с возможностью разрешения зависмостей по UUID

$ sudo apt-get install somename
Reading Package List... Done
Building Dependency Tree... Done
The following NEW packages will be installed:
b078278a894755d1fcb94990db902aff096ba451
4c1360013fe1ad74cf6080da8f7e2f6089395716  
dcfdd015b5e8d55a218d1eb5f3870f2ebdf48a42  
f88a53af1f163a3a23379aba4da5aa5ade357ca3  
29a886243893665fee6e5aaefe8d85a41bb1d9c5  
4754c97ffcf657718e8d7b63081250cf0198d448  
e4df748aff8ce2e66b9a42258f97022d80586486  
14ea4e1358d360793889b2a45188d9353ea7ede9  
b49eff170ba7f721f398518b18007a5096a45d01  
20b8212a2f458811b19f1a6a7cbdeb7d5425fe2b  
dad5473842f7bdfad97fb76e31a1de1a5710c0ce  
5fc6594dbb6a6dd1d1efd3d48f4f61cdd3cb4726  
cdf2461159bba39ca201dfadfa111f1006f8b1bb  
Do you want to continue? [Y/n] _

gdebi для дебиан и форков

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

Нафиг надо.

Атмосферно :)

лол.

Конечно же, должно существовать отображение UUID в человекопонятные имена и в имена пакетов каждого дистра

Хз, что ты имел в виду про UUID, то ты определенно хочешь изобрести pkgsrc

Оно умеет использовать системный пакетный менеджер?

fedora

это и есть пакетный менеджер (и база пакетов), чего ещё надо?

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

# Обычный репозиторий с индексом пакетов
[core]
Type = default
Url = http://someurl/

# Репозиторий без индекса пакетов. Пакетник автоматически строит индекс на основе прочитанного списка файлов
[blabla]
Type = directory
Url = ftp://someotherurl/

# Репозиторий, из которого нас интересуют только пакеты, относящиеся к kde. Остальные игнорируются, как будто их нет.
[somecustomrepository]
Type = default
Url = http://someurl/
OnlyPackages = kde-*

# Репозиторий эмулируется на основе единичного сборочного файла. Если файл обновился, значит будет считаться, что "пакет" обновился. При попытке установить или обновить пакет запустится сборка пакета на локальной машине.
[openbox-custom-build]
Type = pkgbuild
Url = http://someurl/openbox/PKGBUILD

# Ну и так далее. Идея понятна.

＞# Репозиторий, из которого нас интересуют только пакеты, относящиеся к kde. Остальные игнорируются, как будто их нет.

Мне бы какую-нибудь опцию наоборот. Вроде «притвориться, что всё, что с тегом «гном» не существует», например.

Ну подразумевалось, чтобы можно было и наоборот. :)

Предлагаю создать общую базу всех опен(а может даже и
неопен)сорных пакетов с возможностью разрешения
зависмостей по UUID

http://en.wikipedia.org/wiki/AppStream

Это оно и есть. База зависимостей, при чем с учетом дистрибутивной специфики.

Только там еще какой-то крэп приплетен типа бубунтуцентра и иконок приложений, и ни слова про подход к унифицированному разрешению зависимостей

это и есть пакетный менеджер (и база пакетов), чего ещё надо?

Того что бы команда super_install coll-prog-10.0 одинаково проходила во всех дистрибутивах и графических интерфейсах. И имя cool-prog было одинаковым для все дистров.

При чем чтобы прозрачно для пользователя она ставила cool-prog из репозитория дистра, под тем именем в котором оно там лежит, если cool-prog там есть. А если нет лезла в метабазу, качала оттуда и ставила LSB (или еще какую) версию.

А юз-кейс такой - хочет простой человек поставить, например, шарики (такая тупая прога). Он идет на сайт шариков, там лежит открыто ОДИН ФАЙЛ типа шарики.metapackage. Он на него кликает и шарики ставятся.

Но при этом автоматом качается версию для дистрибутива, если есть, LSB версию если нет и автоматом ставит зависимости из репозитория. Даже если шарики в дистрибутиве называются колесики. Так как в .metapackage описано куда лезть за зависимостями для каждого конкретной версии конкретного дистрибутива. И библиотеки зависимостей, берутся из конкретного дистрибутива.

Только там еще какой-то крэп приплетен типа бубунтуцентра и
иконок приложений, и ни слова про подход к унифицированному
разрешению зависимостей

Без унифицированное разрешения зависимостей ни универсального бубунтуцентра ни иконок не будет.

А универсальный бубунтуцентр нужен так простой юзер хочет ставить любой дистр, потом кликать в «хачу прогу под линупс» и она должна просто поставится. При чем хочет кликать в этом самом универсальном бубунтоцентре. Который у него по дефолту зацеплен при установке.

Можно так: программа в виде каталогов и файлов (/usr/bin, /usr/lib и так далее) поставляется вместе с простым установочным bash-скриптом, который и делает всю такую работу.

Всё давно работает.

[root@book viking]# yum localinstall ICAClient-11.100-1.i386.rpm 
Loaded plugins: langpacks, presto, refresh-packagekit
Setting up Local Package Process
Examining ICAClient-11.100-1.i386.rpm: ICAClient-11.100-1.i386
Marking ICAClient-11.100-1.i386.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package ICAClient.i386 0:11.100-1 will be installed
--> Processing Dependency: libXaw.so.7 for package: ICAClient-11.100-1.i386
--> Processing Dependency: libXm.so.4 for package: ICAClient-11.100-1.i386
--> Processing Dependency: libXmu.so.6 for package: ICAClient-11.100-1.i386
--> Processing Dependency: libXp.so.6 for package: ICAClient-11.100-1.i386
--> Running transaction check
---> Package libXaw.i686 0:1.0.8-1.fc15 will be installed
---> Package libXmu.i686 0:1.1.0-2.fc15 will be installed
---> Package libXp.i686 0:1.0.0-16.fc15 will be installed
---> Package openmotif.i686 0:2.3.3-1.fc14 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package       Arch     Version              Repository                    Size
================================================================================
Installing:
 ICAClient     i386     11.100-1             /ICAClient-11.100-1.i386     6.6 M
Installing for dependencies:
 libXaw        i686     1.0.8-1.fc15         fedora                       184 k
 libXmu        i686     1.1.0-2.fc15         fedora                        62 k
 libXp         i686     1.0.0-16.fc15        fedora                        23 k
 openmotif     i686     2.3.3-1.fc14         rpmfusion-nonfree            1.2 M

Transaction Summary
================================================================================
Install       5 Packages

Total size: 8.0 M
Total download size: 1.5 M
Installed size: 10 M
Is this ok [y/N]: 

Вообще меня удивляет, что каждый пакетник понимает только 1 формат репозитория.

http://labix.org/smart

yum localinstall пакет

Автоматом тянет все зависимости для пакета, если такие найдутся в репах.

Федора — точно.

Можно так: программа в виде каталогов и файлов (/usr/bin, /usr/lib и так далее)
поставляется вместе с простым установочным bash-скриптом, который и делает
всю такую работу.

Так нельзя.

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

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