Автор статьи пытается предложить новый подход к управлению программными пакетами в UNIX-системах. Статья отталкивается от реализации подобной схемы в BSD-системах, однако все необходимые для этого вещи присутствуют и в Linux, по-видимому начиная с ядра 2.6. Статья на английском языке.
URL: http://bofh.org.ua/upkg.txt
Новость: http://www.opennet.me/opennews/art.shtml?num=4213
Да.........
Через 2-3 года в RHEE появятся порты
Я не думаю, что RedHat'у вообще захочется как-то менять устоявшийся формат RPM -- в том числе, прикручивать к нему порты.
Никогда не думал что система управления пакетов может зависить от версии ядра. =)
Шикарный ответ :))))) Солидарен!
В Linux - зависит, в BSD - нет... К чему бы это? ;-)
Видимо - к тому, что в Linux до версии 2.5 так и не было нормального Stackable Filesystem Layer :-)))
Собственно, идея-то так себе. Ещё на примере с QNX было видно, как поступать. Делаем /usr/local/opt и симлинки в bin, etc, etc от /usr/local/package/<соответственно>, который, в свою очередь, является симлинком на /usr/local/opt/package-version. Утанавливаем новую версию пакета и меняем симлинк /usr/local/opt/package - телемаркет. Давно уже подобным образом живу. Удобно!
А по-моему классно и очень удобно. Наверное, каждый рано или поздно приходил или придет к такой схеме, но я, например, не знал о union mounts и максимум, что мог придумать - это полжить в /etc/profile.d скрипт для каждого пакета, устанавливающий PATH, а потом читать их при старте шелла, как в slackware.
Прикольнее всего сделано в Mac OS X - там каждый пакет хранится в своей директории, которая для пользователя из finder'а выглядит как один исполняемый файл. Удалил - деинсталлировал.
Ну, про union mount я тоже ничего не знал. :) А MacOS - штука навороченная. Спрашивается только, настолько ли нужны эти навороты? Часто отдельные файлы пакета используется другими пакетами/приложениями, в конце концов. Они, в Apple, ребята весёлые, но склонные к монстроидальности. Вот была Система7 -
вещь. Работала быстро. А теперь что? Сколько памяти надо? Какой процессор?
>Они, в Apple, ребята весёлые, но склонные к монстроидальности. Вот была Система7 -
>вещь. Работала быстро. А теперь что? Сколько памяти надо? Какой процессор?Да, по сравнению с System 7 -- да что там говорить, даже по сравнению с девяткой -- Mac OS X выглядит далеко не так изящно. Но, с другой стороны -- у меня G4/466MHz, 256MB мозгу -- и каких-либо неудобств не испытываю. Даже на работу (на *мою* работу, а не на работу системы) ресурсов вполне достаточно остаётся -- звукомонтаж там, и всё такое.
Я как-то жил по подобной схеме - с симлинками. Всё хорошо, кроме одного: при удалении/обновлении пакета куча геморроя с перетряхиванием всех созданных симлинков. Как на меня, так union mounts должны решить как раз проблему с симлинками. В QNX 6, по-моему, вместо симлинков как раз используется нечто вроде union mounts.
Перетряживать ничего не надо, если новых файлов не появилось. Потому что все симлинки идут из /usr/local/opt/package, а программа ставится в /usr/local/opt/package-version.
Хм. Иногда новые файлы появляются. Например /opt/package/lib/libfoo.so.X, где X вполне спокойно может меняться.Кроме того, что находится в /usr/local/opt/package, если оттуда симлинки идут? Там находится ещё один комплект симлинков, что-ли? Не вполне улавливаю ход мысли.
В принципе, в какой-то момент я вполне себе убедился, что симлинки -- выход. Однако unionfs как-то изящнее получается, что-ли. Движений меньше делать нужно.
> Хм. Иногда новые файлы появляются. Например /opt/package/lib/libfoo.so.X, где X вполне спокойно может меняться.Обрабатывать скриптом. Тут ничего не поделаешь. Да и не особо сложно это.
Объёмы не те, потому делаю руками. Проверяю. Иногда откатываюсь.> Кроме того, что находится в /usr/local/opt/package, если оттуда симлинки идут?
make DESTDIR=/usr/local/opt/package-version install
ln -s /usr/local/opt/package-version /usr/local/opt/package
ln -s /usr/local/opt/package/bin/* /usr/local/bin
... и так далее> В принципе, в какой-то момент я вполне себе убедился, что симлинки -- выход. Однако unionfs как-то изящнее получается, что-ли. Движений меньше делать нужно.
Для меня тут один недостаток, у union mount, как и у bind, - чётко не видно откуда ноги растут у файла. Всё равно, что хардлинк на каталог получается. С union ситуация усугубляется. И ещё, думаю, дополнитеные накладные расходы в результате работы через vfs должны присутствовать.
А то, что фича появилась - ХОРОШО. %)
Хе-хе дааа... порты и портаджи уже не рулят хотя работают замечательно :)
>Хе-хе дааа... порты и портаджи уже не рулят хотя работают замечательно :)гы-гы..
/me nodsIMHO конкретная реализация системы пакетов имеет весьма второстепенное значение по сравнению с главным фактором: на сколько активно и своевременно система поддерживается разработчиками. тому-же pkgsrc от NetBSD была бы грош цена, если бы столько народу постоянно не вбухивало в него свои силы и время.
ps: допустим, какая мне радость от наворотов системы пакетов, если я все равно не могу собрать последние kdelibs3 или icewm в силу мелких недочетов при их внесении в порты.. :)
// wbr
Или еще можно вспомнить, как это сделано в NeXTSTEP/OpenSTEP/GNUStep. В принципе точно так же, как и в Mac OS X, тоже пакету соответствует директория .App
Правда, кроме калькулятора и блокнота под gnustep ничего нет. И не девелопят его уже давно, а жаль.