После того как я увидел systemd в Zero Install я подумал что можно создать дистрибутив, полностью основанный на Zero Install, а не RPM и DEB. Попробовал поискать и ничего не нашёл, ни на сайте проекта, ни в Google.
Такие вещи должны лежать под управлением традиционного пакетного менеджера.
LSB, система инициализации и т.п. будут в rpm/deb/чем-то-еще.
А вот все приложения и высоуровневые библиотеки пакетировать в 0install.
И в идеале, эти пакеты будут совместимы с любой LSB-совместимой системой.
И сколько же денег для этого надо?
Сейчас понятия не имею. У меня есть только готовность взяться за подобный проект. Но конкретного бизнес-плана я не составлял.
я подумал что можно создать дистрибутив, полностью основанный на Zero Install
Вообще говоря, не стоит инструмент использовать не по назначению. Zero Install разрабатывался для управления прикладным ПО, использовать его для системного нет нужды.
> И в идеале, эти пакеты будут совместимы с любой LSB-совместимой системой.
Ничего себе. Так значит если дистрибутив поможет популяризировать Zero Install, на всех сайтах будет один файл для Linux, а не как сейчас! Сейчас таким образом распространяют только закрытое ПО, а бинарники открытого ПО не запускаются не только между двумя дистрибутивами Linux, но и между двумя релизами одного дистрибутива. Например Wine.
#!/bin/sh
# Change to game directory
CANONPATH=`readlink -f "$0"`
cd "`dirname "$CANONPATH"`"
MACHINE=`uname -m`
if [ "$MACHINE" = x86_64 ]
then
BIN=./Osmos.bin64
else
BIN=./Osmos.bin32
fi
$BIN $@
e=$?
exit $e
World Of Goo: WorldOfGoo, WorldOfGoo.bin32, WorldOfGoo.bin64.
#!/bin/sh
# Change to game directory
CANONPATH=`readlink -f "$0"`
cd "`dirname "$CANONPATH"`"
if [ ! -e properties ] || [ ! -e res ]
then
echo "Missing properties/ and res/ directories in `pwd`"
echo "Your installation is incomplete!"
exit 1
fi
# Uncomment the line below to dump core when the game crashes; useful for
# debugging, but only works if the game directory is user-writable!
#ulimit -c unlimited
MACHINE=`uname -m`
if [ "$MACHINE" = x86_64 ]
then
LIBS=./libs64
BIN=./WorldOfGoo.bin64
else
LIBS=./libs32
BIN=./WorldOfGoo.bin32
fi
# Run the game:
export LD_LIBRARY_PATH=$LIBS:"$LD_LIBRARY_PATH"
$BIN $@
# Check for errors
e=$?
if [ $e -ne 0 ]
then
echo ""
echo "It looks like World of Goo crashed! If you need support, please include the"
echo "contents of the log file in your problem report."
LOGPATH="$HOME/.WorldOfGoo/WorldOfGoo.log"
if [ -f "$LOGPATH" ]
then
echo "The log file is stored at: $LOGPATH"
echo "" >> $LOGPATH
echo "Libraries used:" >> $LOGPATH
ldd $BIN >> $LOGPATH 2>&1
echo "" >> $LOGPATH
GLXINFO=`which glxinfo`
if [ -z "$GLXINFO" ]
then
echo "glxinfo not found!" >> $LOGPATH
else
echo "Output of glxinfo:" >>$LOGPATH
glxinfo >>$LOGPATH 2>&1
fi
else
echo "Unfortunately, no log file has been created!"
fi
fi
exit $e
VVVVVV: VVVVVV, VVVVVV_32, VVVVVV_64.
#!/bin/sh
# Change to game directory
CANONPATH=`readlink -f "$0"`
cd "`dirname "$CANONPATH"`"
# Check resource folders exist
if [ ! -e data ]
then
echo "You are missing games resources `pwd`"
echo "Your installation is incomplete!"
exit 1
fi
MACHINE=`uname -m`
if [ "$MACHINE" = x86_64 ]
then
LIBS=./LIB64
BIN=./VVVVVV_64
else
LIBS=./LIB32
BIN=./VVVVVV_32
fi
# Run the game:
export LD_LIBRARY_PATH=$LIBS:"$LD_LIBRARY_PATH"
$BIN $@
И Trine и Amnesia очень похоже, только с Launcher'ом. Но сейчас показать не могу
мы про генту и юз-флаги или про бинарный пакетный менеджер nix?
Source-based model, with binaries
The Nix build language used by NixOS specifies how to build packages from source. This makes it easy to adapt the system — just edit any of the ‘Nix expressions’ for NixOS or Nixpkgs in /etc/nixos, and run nixos-rebuild. However, building from source is also slow. Therefore Nix automatically downloads pre-built binaries from nixos.org if they are available. This gives the flexibility of a source-based package management model with the efficiency of a binary model.
Any questions?
молодец, ставить оценки себе научился, теперь осталось подтянуть матчасть в этом направлении и вообще отличным обезьяном будешь.
Да, тебе не помешает подтянуть матчасть и прочитать мануал по nix package manager. А за одно и по 0install.
Я-то с обоими пакетными системами знаком, а ты тут горбатого лепишь.
т.е. я могу считать apt-get-source (или как там) или арч source-based? Если да - то вопросов нет.
Господи, дерево. Иди уже читай мануал. Состояние собранной системы в nix представляет собой вычисление огромного выражения на функциональном ЯП. Вычисление производится над исходным кодом. На этом принципе построена система. То, что отдельные узлы дерева предвычислены и закэшированы, абсолютно не меняет этого принципа, это исключительно вопрос реализации.
т.е. я могу считать apt-get-source (или как там) или арч source-based?
Нет, ты не можешь считать deb-систему source-based, потому что она рассчитана на распространение и установку ПО в собранном виде. А nix предназначен для вычисления состояния системы по исходному коду. Этого его предназначение, понимаешь? Он для этого спроектирован. Люди, сели, подумали, сформулировали задачу и написали код. Задача всегда первична. И та задача — совсем иная, чем у deb. Как тебе, еще объснить? Если ты изменишь одну букву в спецификации пакета, он будет автоматически пересобран при обновлении мира, а deb — не будет. Ферштейн?
А теперь ответь мне, зачем ты приперся со своим функциональным ПМ в тред, где обсуждается 0install и вопросы распространения ПО в бинарном виде?
FatELF мне нравится, я считаю что если бы Icculus закончил в тот раз работу, всем было бы хорошо от этого. «Велосипеды» нужны для того чтобы в одну RPM-ку и DEB-ку положить 32- и 64-битные бинарники, и распространять два бинарника, а не 4, как многие делают.
Что касается засовывания в FatELF всех либ, я здесь вижу два недостатка 1). 64-мегабайтный бинарник вместо двух 1-мегабайтных 2). Иногда выходят обновления безопасности для системных библиотек. В случае если игра с поддержкой мультиплеера использует динамические библиотеки /usr/lib*.so, всё будет хорошо. В случае если используется статическая линковка, всех игроков под Linux'ом будут взламывать.
Появится, как только вы все скинетесь и профинансируете мне создание такого проекта. :-D
В Каноникал уже подумывают над запиливанием этой концепции у Убунте, так что сейчас уже нет большого смысла городить новый дистр с этой фичей. Разве что если Каноникал дальше слов не пойдёт опять.
У этого вашего 0install эталонно бестолковый туториал. Одни скриншоты, епт. В чем суть системы?
Ну ты даешь! Нормальный у него мануал.
Суть системы в том, что:
Приложение должно быть собрано так, чтобы запускаться с с произвольным префиксом.
У приложения есть манифест, лежащий по некоторому URL. Там указано, где брать архив с приложением, какие ему нужны зависимости и как приложению при запуске сообщить, где лежат его зависимости.
Приложение запускается командой 0launch url. При этом, если его еще нет локально, оно выкачивается, затем рекурсивно выкачиваются зависимости. В указанные в манифесте переменные окружения помещаются пути к зависимостям (например формируется нужный PATH и LD_LIBRARY_PATH) и происходит запуск приложения.
Логически вся адресация выполняется на основе URL, по которым лежат манифесты, и контрольных сумм. Где физически будет размещен пакет, не важно.
Вот и всё. Плюс есть дополнительные плюшки, такие как размещение приложения в меню путём переноса его *.desktop-файла в ~/.local/share/applications/, или фоновая проверка обновлений.
Также есть интеграция с основным ПМ системы (чтоб не скачивать то, что уже установлено в /usr) и возможность переопределить интерфейсы («вот тот URL на самом деле брать вот по этому URL»).
Приложение запускается командой 0launch url. При этом, если его еще нет локально, оно выкачивается
Какой песец.
Вот и всё.
Это куча ненужных деталей, на самом деле. Интересна суть - как он взаимодействует с пакетным менеджером системы (если взаимодействует)? Как описываются требования к системе (если описываются), или ему не нужно ничего, кроме glibc, или молчаливо предполагается какой-то набор библиотек? Есть ли зависимости между 0install-пакетами и, если есть, как они описываются? Есть ли какие-нибудь средства автоматизации сборки?
Это куча ненужных деталей, на самом деле. Интересна суть
Бгг. Я тебе объяснил суть: каждый пакет представлен как URL. Манифест, лежащий по URL-у, описывает свойства пакета, включая и зависимости. Зависимости также представлены как URL. (пример: http://rox.sourceforge.net/2005/interfaces/ROX-Filer)
Фактически, это реализация опенсорсного распределенного Андройд/Эппл/whatever-маркета.
А то, что ты сейчас спрашиваешь, как раз и есть куча деталей.
Есть ли зависимости между 0install-пакетами и, если есть, как они описываются?
Чувак, ты вроде раньше не был замечен в том, что не читаешь то, на что отвечаешь. Я для кого писал, что зависимости резолвятся по URL?
Интересна суть - как он взаимодействует с пакетным менеджером системы (если взаимодействует)?
Я то же самое могу сказать о любом deb или rpm, лежащем на ftp или http.
Не можешь, потому что для твоего rpm URL не служит идентификатором для разрешения зависимостей.
Я спрашивал, есть ли зависимости между пакетами, а не как они резолвятся. Если зависимости есть, то должен быть депсолвер.
То есть ты допускаешь, что зависимости резолвятся, но при этом их нет? :D Иди проспись.
Этот 0install всё больше напоминает ненужную переделку yum+RPM/apt+dpkg, прикрытую слоем для автоматического скачивания пакетов.
Ну разумеется всё, что позволяет без головной боли ставить пакеты, не надрачивая на «рипазитории», в линуксе объявляется ненужным. :-D Давно dpkg научился ставить пакеты по произвольным префиксам и заставлять их корректно работать в таких условиях, не подскажешь?
для твоего rpm URL не служит идентификатором для разрешения зависимостей.
Правда штоле?
wget $URL | rpm2cpio | cpio --extract
вот тебе и манифест - разрешай зависимости.
Я спрашивал, есть ли зависимости между пакетами, а не как они резолвятся. Если зависимости есть, то должен быть депсолвер.
То есть ты допускаешь, что зависимости резолвятся, но при этом их нет? :D Иди проспись.
То есть депсолвер в нем есть. Ну, молодцы, чо.
Ну разумеется всё, что позволяет без головной боли ставить пакеты, не надрачивая на «рипазитории», в линуксе объявляется ненужным. :-D
Если ты не помнишь времен, когда репозиториев не было, или не видишь репозиториев в 0install - тебе нужен отдых и учебник истории.
Давно dpkg научился ставить пакеты по произвольным префиксам и заставлять их корректно работать в таких условиях, не подскажешь?
dpkg не умеет префиксов. Но я тебе страшную вещь скажу - это только часть функционала пакетного менеджера. И вместо того, чтобы научить этому dpkg (или взять RPM, который умеет в префиксы), разрабы 0install сделали что-то свое. Зачем? Я уверен, что ты это понимаешь - расскажи нам.
tailgunner емнип этот велосипед появился в районе opensuse версии эдак 10. И там его позиционировали как «альтернативу сложному rpm для еще неопакеченного софта» пытаясь представить все так как будто бы любая домохозяйка которая осилит написать свою мегопрограммку но не осилит её опакетить найдет простое решение в зераынсталле. На словах это выглядело именно так. На деле толку от него было мало.
не видишь репозиториев в 0install - тебе нужен отдых и учебник истории.
В 0install нет репозиториев. Для 0install есть каталоги фидов. Это исключительно средство поиска ПО для пользователя. Оно не больше «репозиторий», чем какой-нибудь http://www.alternative.to/
Сам 0launch никакими репозиториями при разрешении зависимостей не пользуется. Можешь считать, что репозиторием для него служит вся глобальная сеть целиком.
dpkg не умеет префиксов. Но я тебе страшную вещь скажу - это только часть функционала пакетного менеджера. И вместо того, чтобы научить этому dpkg (или взять RPM, который умеет в префиксы), разрабы 0install сделали что-то свое. Зачем? Я уверен, что ты это понимаешь - расскажи нам.
Наверное затем, что не стоит переделывать отвертку в инструмент для удобного забивания гвоздей. ПМ, использующий централизованный репозиторий и фиксированные пути установки ПО, отлично подходит для сборки и конфигурации базовых компонентов системы — которые в рамках работы над дистрибутивом централизованно опакечиваются и тестируются. Если ты хочешь ставить и использовать пакеты с glibc или coreutils по произвольным путям в произвольной среде, ты явно что-то делаешь не так.
У ПМ для прикладного ПО совсем другие требования, проистекающие из требований к этому ПО. Оно должно быть «собрано однажды, работает везде». Именно эту задачу решает 0install, и всего фичи на это и нацелены.
Указанная ссылка на фид rox-filer запустит тебе его в любой совместимой системе. В частности, данный фид содержит сборки под платформы: rox-filer-linux-x86_64-2.11.tar.bz2, rox-filer-freebsd-i386-2.11.tar.bz2, rox-filer-linux-i486-2.11.tar.bz2. И теоретически там может лежать сколько угодно сборок: хоть для миникса, хоть для макоси.
В 0install нет репозиториев. Для 0install есть каталоги фидов. Это исключительно средство поиска ПО для пользователя.
Наверное, ты не застал систем, у которых репозиторием был просто каталог с пакетами.
Можешь считать, что репозиторием для него служит вся глобальная сеть целиком.
Круто. Для целей маркетинга - самое то, но у меня другая специальность.
ПМ, использующий централизованный репозиторий и фиксированные пути установки ПО, отлично подходит для сборки и конфигурации базовых компонентов системы
У ПМ для прикладного ПО совсем другие требования, проистекающие из требований к этому ПО
Вот в этом и есть твоя главная ошибка. У «прикладного» ПО требования очень близкие (возможно, просто идентичные). Ты принимаешь за другие _требования_ другое _дерево зависимостей_.
И теоретически там может лежать сколько угодно сборок: хоть для миникса, хоть для макоси.
Наверное, ты не застал систем, у которых репозиторием был просто каталог с пакетами.
У тебя уже каталог с пакетами научился волшебным образом себя выкачивать из интернета, распаковываться, настраиваться и запускаться? А я ведь еще полсуток назад тебе говорил: выспись.
Круто. Для целей маркетинга - самое то, но у меня другая специальность.
Ну если ты разучился в русский язык, то самое время попробовать себя в маркетинге.
Ты принимаешь за другие _требования_ другое _дерево зависимостей_.
Это _дерево зависимостей_ является _децентрализованным_. Нет никакого владельца репозитория, который может разместить или не разместить твой пакет. Нет никакого /etc/apt/sources.list. Нет зависимости алгоритма резолвинга от базы данных с именами пакетов.
Повторить по слогам? :}