Минималистический подход к управлению пакетами в UNIX

Re: Минималистический подход к управлению пакетами в UNIX

Нет, ну надо было на английском запостить в ЛОР. Ведь сам же русский ...

Re: Минималистический подход к управлению пакетами в UNIX

а на какие фичи так туманно намекается, на mount --bind чтоли?
Оно не "по видимому в версии 2.6" а с 2.4 как минимум.
На слаке, возможно, даже с 2.2.

Re: Минималистический подход к управлению пакетами в UNIX

Да, давненько я такого бреда не читал :-) Даешь новый /Program Files/Program/Version/Subversion и 1000 майнтпоинтов!!! :-)

А как быть с теми пакетами, которые и не должны располагаться в /usr/local, например mount, grep, pam, binutils и прочими? Или они типа за пакеты уже не считаются?

А если установлено 150 пакетов, их каталоги lib собраны на /usr/local/lib, в каждом пакете 10 билиотек... И теперь какая-нибудь программа пытается загрузить 15 библиотек. И что, ядро для каждой из них лезет в таблицу маунтов, видит что /usr/local/lib это union, пробегает по каждому элементу union'а в поисках нужного файла...

Нет, пусть лучше это бзд-ючники у себя реализовывают, а мы оставим mount для файловых систем :-)

P.S.: а почему мальчику не пришло в голову просто накидывать в /usr/local/xxx симлинки???

no-dashi (11.08.2004 14:22:40)

идиотический подход к управлению пакетами в UNIX

Опять этот C:\Program Files\ вылез...

Dselect (11.08.2004 14:36:24)

Re: Re: Минималистический подход к управлению пакетами в UNIX

В тему. В ASP 9.0 зависимости пакетов установлены так, что KDE нельзя поставить без Gnome.

Eugene_Korobko (11.08.2004 14:37:30)

Re: Re: Re: Минималистический подход к управлению пакетами в UNIX

> В ASP 9.0 зависимости пакетов установлены так, что KDE нельзя поставить без Gnome

Или все-таки без gnome-libs? :-)

Тебе 10 метров на гномовские библиотеки жалко? :-)

no-dashi (11.08.2004 14:59:06)

Re: Re: Минималистический подход к управлению пакетами в UNIX

Ставь себе хоть замок на молнии на брюках на ширинке. Сейчас ты этим никого не испугаешь. Насмотрелись торчащий и не закрытый ничем. Почему дуракам из BSD пришлось малую песочницу организовывать? Дурилка и есть дурилка.

Re: Re: Re: Re: Минималистический подход к управлению пакетами в UNIX

кстати а зачем КДЕ вдруг понадобились Gnome-libs даже?

ASTAROT (11.08.2004 15:13:45)

Re: Re: Re: Re: Re: Минималистический подход к управлению пакетами в UNIX

А это не обязательно - просто система конфигурирования дистра с гуями может юзать эту либу, и при X-ах она может ставится автоматом.

Аналогия - в федорином Горе 2-м ставится python-gnome и т.д., которая судя по всему юзается только их конфигураторами, и для Gnome вобщем-то не нужна.

Spectr (11.08.2004 15:21:36)

Re: Минималистический подход к управлению пакетами в UNIX

Статья эта - сопли. Ну, так, некие рассуждения в слух. Рекомендую
автору для начала провести исследование уже сделанных проектов по
данной тематике. Их десятки. Некоторым по многу лет и они активно
поддерживаются. Один из лучших примеров - epkg:
http://www.encap.org/epkg/
Изучите его внимательно. Там всё это уже реализовано и работает.

annonymous (11.08.2004 15:24:44)

Re: Re: Re: Минималистический подход к управлению пакетами в UNIX

наглое вранье либо очень кривые руки

Re: Re: Re: Re: Re: Re: Минималистический подход к управлению пакетами в UNIX

ну к примеру игры гномовские некторые тоже требуют питона

Re: Re: Минималистический подход к управлению пакетами в UNIX

mount --bind совсем не то. Я не слышал чтобы в любимом линуксе была фича типа unionfs. Советуюю почитать что это такое и все станет ясно.

Пример из жизни - крутится 40 jail'ов на одном серваке. Так вот чтобы не клепать 40 файловых систем (тем самым сабивая и без того малюсенький сказочный хардец), делаешь один темплейт, и используешь его для всех джейлов. Места экономится %40-50.

FreeBSD (11.08.2004 15:53:43)

Re: Re: Минималистический подход к управлению пакетами в UNIX

> А как быть с теми пакетами, которые и не должны располагаться в /usr/local, например mount, grep, pam, binutils и прочими? Или они типа за пакеты уже не считаются?

Нет, не считаются. Если оно не в local, то оно - часть base system, и ставится через make world; во всяком случае, у людей =)

> А если установлено 150 пакетов, их каталоги lib собраны на /usr/local/lib, в каждом пакете 10 билиотек... И теперь какая-нибудь программа пытается загрузить 15 библиотек. И что, ядро для каждой из них лезет в таблицу маунтов, видит что /usr/local/lib это union, пробегает по каждому элементу union'а в поисках нужного файла...

А кто мешает оптимизировать ядро под такие вещи?

> а почему мальчику не пришло в голову просто накидывать в /usr/local/xxx симлинки???

Очевидно, потому что тогда удаление пакетов через rm работать не будет - останется туева хуча симлинков. Так что все равно придется заводить базу пакетов, чего он старается избежать.

Вообще идеи имхо интересные (хотя и не новые), но дело в том, что нынешние пакадж-менеджеры с базами очень даже неплохо справляются. Такая система имеет смысл разве что при установке большого количества пакетов ручками (я кстати по жизни в дженте весь самосбор в /opt ставлю).

int19h (11.08.2004 16:33:05)

Re: Re: Re: Минималистический подход к управлению пакетами в UNIX

> mount --bind совсем не то. Я не слышал чтобы в любимом линуксе была фича типа unionfs. Советуюю почитать что это такое и все станет ясно.

Почитал man mount_unionfs:

"THIS FILE SYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T WORK) AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM. USE AT YOUR OWN RISK. BEWARE OF DOG. SLIPPERY WHEN WET. This code also needs an owner in order to be less dangerous - serious hackers can apply by sending mail to <hackers@FreeBSD.org> and announcing their intent to take it over."

И стало как-то не по себе =)

int19h (11.08.2004 16:40:55)

Re: идиотический подход к управлению пакетами в UNIX

> Опять этот C:\Program Files\ вылез...

В таком случае FHS тоже пропагандирует C:\Program Files ;-) Вот она, грязная и немытая лапа Мелкософта - уже и до FHS добрались :-)))

Re: Re: идиотический подход к управлению пакетами в UNIX

> В таком случае FHS

"Лев был царь зверей. А по закону царей 3.14здить не положено. Но звери давно забили на закон."

s/Лев/FHS

Да кому он здесь нужен, этот FHS?

Re: Re: Минималистический подход к управлению пакетами в UNIX

> Нет, ну надо было на английском запостить в ЛОР. Ведь сам же русский...

Это точно. Ведь давно известно, что пионерия на ЛОРе английского не знает.

Re: Re: Минималистический подход к управлению пакетами в UNIX

> Нет, пусть лучше это бзд-ючники у себя реализовывают, > а мы оставим mount для файловых систем :-)

Ясное дело, BSD-шники дибилы. А так же дибилами являются RMS и его Hurd'овский зоопарк.

Но самые главные дибилы -- вот эти ребята:

Charles P. Wright PhD May 2003 Mohammad Nayyer Zubair MS May 2003 Jay Pradip Dave MS May 2003 - Dec 2003 Software Engineer, Zetta Systems Inc. (Woodinville, WA) Puja Gupta MS Jan 2003 - Dec 2003 File Systems Engineer, Apple (Cupertino, CA) Harikesavan Pathangi Krishnan MS Jan 2003 - Dec 2003 Tacit Networks (South Plainfield, NJ) Mohammad Nayyer Zubair BS May 2003 - Dec 2003 Stony Brook U. CS M.S. program (Stony Brook, NY)

http://www.fsl.cs.sunysb.edu/project-unionfs.html

UnionFS -- зло! Давить! Давайте дальше жить в помойке!

Re: Re: Минималистический подход к управлению пакетами в UNIX

> P.S.: а почему мальчику не пришло в голову просто накидывать в /usr/local/xxx симлинки???

Потомо, что без них изящнее, тормоз. И 1000 mount-point'ов у тебя будет только если ты, как и подобает тормозу, зафигачишь в систему 1000 пакетов.

Re: Re: Re: Минималистический подход к управлению пакетами в UNIX

>>Нет, не считаются. Если оно не в local, то оно - часть base system, и ставится через make world; во всяком случае, у людей =)

Самый большой дебилизм, который есть в *BSD, это концепция base system, мешающая нормальному обновлению базового набора приложений и библиотек.

>А кто мешает оптимизировать ядро под такие вещи?

Тот факт, что ядро, затачиваемое под package manager -- плохое ядро. Не его ядреное это дело.

Zulu (11.08.2004 17:56:31)

Re: Re: Re: Re: Минималистический подход к управлению пакетами в UNIX

правильнее когда ядро отдельно, да ? :)

W (11.08.2004 18:14:06)

мальчик с феноманальной памятью...

> А кто мешает оптимизировать ядро под такие вещи?

Ох, не ядреное это дело...

> Очевидно, потому что тогда удаление пакетов через rm работать не будет

А оно и так не будет работать _корректно_.

> Так что все равно придется заводить базу пакетов, чего он старается избежать.

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

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

Я поначалу подумал (когда увидел слова про 2.6.x), что он базу собирается в xattr засунуть -- но нет, старый добрый идиотизмъ в запущенной форме...

Dselect (11.08.2004 18:16:46)

Re: мальчик с феноманальной памятью...

> ldconfig пущать, когда нужно и т.п.?

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

что такое "вручную"

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

Таким образом, отличия от нормального package manager'-а сводятся к:

1) нарушению FHS

2) хранению кучи практически идентичных скриптов в директории каждого пакета, каждый из этих скриптов -- это недо-package manager, такой зоопарк выйдет...

Может, таки лучше, чтоб мухи были отдельно, а котлеты -- отдельно?

> Главное чтоб это не мешало ручной манипуляции.

А чем Вам dpkg в этом мешает?

Dselect (11.08.2004 18:32:47)

Re: Re: Re: Минималистический подход к управлению пакетами в UNIX

> И 1000 mount-point'ов у тебя будет только если ты, как и подобает тормозу, зафигачишь в систему 1000 пакетов

А "чиста риальные патсаны" типа тебя предпочитают kde-libs, kdemultimedia, arts, kde-games, kde-libs-devel, kde-multimedia-devel, arts-devel и еще 50 компонентов держать одной большой кучей...

Давай-давай...

no-dashi (11.08.2004 19:10:04)

Re: Минималистический подход к управлению пакетами в UNIX

apt-get рулит не падецки

Re: Re: Re: Re: Минималистический подход к управлению пакетами в UNIX

концепция base system позволяет разделить базу от остальной херни. и обновляется она с пол пинка.

Re: Re: Минималистический подход к управлению пакетами в UNIX

Plan 9 -- вот кто рулит не по-детски.

Там объединения ФС реализованы изначально, а не натягиваются, как навороченный, но слишком маленький презерватив...

Re: Re: Re: Re: Re: Минималистический подход к управлению пакетами в UNIX

> концепция base system позволяет разделить базу от остальной херни.

Концепция base system vs все остальное живет от кривых рук и тяжкого наследия. named - это base или не base? Base. А dhcpd? Не base. А httpd? Снова не base. А почему один base, а другие нет? Ведь система и без named, и без httpd работоспособна?

А как определить влияние компонентов base на компоненты не base? На какие программы повлияет апдейт libnss_ldap.so?

no-dashi (11.08.2004 21:38:06)

какой такой kde-libs?

> А "чиста риальные патсаны" типа тебя предпочитают kde-libs, kdemultimedia, > arts, kde-games, kde-libs-devel, kde-multimedia-devel, arts-devel и еще 50

Не знаю, кто такие "чиста риальные патсаны", но у приличных людей перечисленное Вами барахло отсутствует как класс.

P.S.

Да, анонимус, конечно, бред несет.

P.P.S.

$ dpkg --get-selections | grep -e '\<install\>' | wc -l 868

Dselect (11.08.2004 22:14:31)

Re: Re: Re: Re: Минималистический подход к управлению пакетами в UNIX

> концепция base system, мешающая нормальному обновлению базового набора приложений и библиотек.

Я не понял, а чем тебя CVS и make world не устраивают?

> Тот факт, что ядро, затачиваемое под package manager -- плохое ядро. Не его ядреное это дело.

Я говорил не о затачивании ядра под pkg-manager (хотя, в пределах того, что пихается в ядро - почему бы и нет?), а о оптимизации unionfs.

int19h (11.08.2004 22:56:25)

Re: мальчик с феноманальной памятью...

> Ох, не ядреное это дело...

Хорошо, оговорюсь: ФС. Которая в данном случае входит в ядро, но вообще-то совершенно не обязана там быть. Так лучше?

> А оно и так не будет работать _корректно_.

Тпрру, а в чем дело? rm -rf /opt/pkg-name и все дела. Что не так?

> А запоминать, какой софтине чего нужно, и разруливать, в каком порядке их ставить/удалять этот мальчик с феноменальной памятью сам будет? ldconfig пущать, когда нужно и т.п.?

Депы естественно кидаются в папку самой софтины.

> Все равно надо будет заводить базу пакетов, иначе получится та же помойка, что в windoze.

Я так понял ему не нравится не идея базы сама по себе, а идея базы как физически отдельной сущности. Т.е. мысля была размазать ее по самим пакетам-каталогам на уровне ФС.

int19h (11.08.2004 22:59:45)

Re: что такое "вручную"

> 1) нарушению FHS

А был ли мальчик?

> 2) хранению кучи практически идентичных скриптов в директории каждого пакета, каждый из этих скриптов -- это недо-package manager, такой зоопарк выйдет..

О каких скриптах речь? Вроде говорили о депах и прочей metainfo? А манагер пакетов - отдельный скрипт, он сам по себе...

> А чем Вам dpkg в этом мешает?

Если ставить много софта ручками, и все в /usr (или куда там его dpkg ставит), то потом этот самый софт ручками тяжело выискивать и удалять.

int19h (11.08.2004 23:02:05)

Re: какой такой kde-libs?

> Не знаю, кто такие "чиста риальные патсаны", но у приличных людей перечисленное Вами барахло отсутствует как класс.

Покажите мне нормальный аудиоплеер под линух/бсд с библиотекой, масс-тэггингом, и распихиванием файлов по каталогам согласно тегам, кроме JuK (который входит в kde-multimedia).

int19h (11.08.2004 23:03:27)

Re: Re: Re: Re: Минималистический подход к управлению пакетами в UNIX

> И стало как-то не по себе =)
Ну, у меня это приводило только к неожиданному кернелпанику и перезагрузке.
В общем, nfs рулит :D

Shadow (12.08.2004 1:24:29)

Re: Re: Re: Минималистический подход к управлению пакетами в UNIX

> почему не пришло в голову просто накидывать в симлинки???

> Очевидно, потому что тогда удаление пакетов через rm работать не будет - останется туева хуча симлинков.

И что? Прошёлся ночером поиском, да и стёр. Вообще говоря, почему не кидать симлинки, я не понял ещё когда впервые сел на Линукс - RedHat 6.0

С уважением -- Смоляное Чучелко

Re: Re: мальчик с феноманальной памятью...

угу... давно уже пора древовидную фс изжить как класс - что-то типа ERFS нужно...

plan9 не plan9 - имеем простой интерфейс - файл называется, а сверху - бардак. Навесили бы на линюк что-то типа COM и пиздец - зависимости сразу видны, узнал GUID и скачивай нужный пакет

hooj (12.08.2004 3:47:35)

Re: Re: Re: Re: Минималистический подход к управлению пакетами в UNIX

>> И 1000 mount-point'ов у тебя будет только если ты, как и подобает тормозу, зафигачишь в систему 1000 пакетов

>А "чиста риальные патсаны" типа тебя предпочитают kde-libs, kdemultimedia, arts, kde-games, kde-libs-devel, kde-multimedia-devel, arts-devel и еще 50 компонентов держать одной большой кучей...

У нормальных людей этого говна вообще нету.

rk (12.08.2004 4:19:59)

Re: Re: что такое "вручную"

> Если ставить много софта ручками, и все в /usr

НАХУЯ СТАВИТЬ СОФТ РУЧКАМИ??!!!! Это что, новый способ дрочить, или что? Сказал apt-get install, и поставил. Сказал apt-get remove, и удалил. Если надо пересобрать, то сказал apt-get source, и пересобрал.

Что только люди не придумают, лишь бы нормально не работать...

rk (12.08.2004 4:23:01)

Re: Re: Re: Re: Re: Минималистический подход к управлению пакетами в UNIX

> > А "чиста риальные патсаны" типа тебя предпочитают kde-libs, kdemultimedia, arts, kde-games, kde-libs-devel, kde-multimedia-devel, arts-devel и еще 50 компонентов держать одной большой кучей...

> У нормальных людей этого говна вообще нету.

А вот теперь скажи, нормальный человек, как без artsd/esd или еще какого-нибудь аудиосервера запустить mplayer или xmms на компе "X", так, чтобы звук выводился на комп "Y"?

no-dashi (12.08.2004 8:04:32)

Re: Re: Re: Re: Re: Re: Минималистический подход к управлению пакетами в UNIX

> аудиосервера запустить mplayer или xmms на компе "X", так, чтобы звук выводился на комп "Y"?

ясное дело. взять plan9 или qnx а не поделку студента... ;)

ivlad (12.08.2004 9:06:55)

Re: Re: мальчик с феноманальной памятью...

> Тпрру, а в чем дело? rm -rf /opt/pkg-name и все дела. Что не так?

Не, rm -Rf /opt/libblah-x.y.z просто так не сойдет.

Надо сначала узнать, не нужна ли какой-то софтине эта libblah, удалить таковой софт, после чего пущать ldconfig. Затем надо проверить, не остались ли какие-то пакеты, которые нужны только libblah, и с их тоже удалить.

> Депы естественно кидаются в папку самой софтины.

> Т.е. мысля была размазать ее по самим пакетам-каталогам на уровне ФС.

Ото я и говорю -- C:\Program Files\. Мож таки сначала надо понять, почему одни штуковины живут в /usr, а другие -- в /var?

Dselect (12.08.2004 9:31:47)

модульность, твою дивизию...

> А вот теперь скажи, нормальный человек, как без artsd/esd или еще какого-нибудь аудиосервера запустить mplayer или xmms на компе "X", так, чтобы звук выводился на комп "Y"?

1) Пользовать нормальную ОСь, а не ....

2) А на# аудиосерверу вся эта Qета (kde-libs, etc)?!

Dselect (12.08.2004 9:38:57)

Re: Re: что такое "вручную"

> Если ставить много софта ручками,

1) А зачем?

2) А пакет собрать ну никак нельзя. Видать, за это дают 10 лет с конфискацией...

Dselect (12.08.2004 9:41:38)

Re: модульность, твою дивизию...

> А на# аудиосерверу вся эта Qета (kde-libs, etc)

Ок. А если я хочу собрать и запускать не XMMS, а kreversi (ну нравится мне как она играет)?

no-dashi (12.08.2004 10:51:25)

Re: Re: Re: мальчик с феноманальной памятью...

> Надо сначала узнать, не нужна ли какой-то софтине эта libblah, удалить таковой софт, после чего пущать ldconfig. Затем надо проверить, не остались ли какие-то пакеты, которые нужны только libblah, и с их тоже удалить.

Ты типа не понял =) Это - задача пакет манагера, отслеживание зависимостей etc, и он должен ее выполнять вне зависимости от организации файлопомойки на диске. Но если вдруг мне приспичило снести вот эту конкретную либу, и я отвечаю за то, что после этого все будет нормально - вот тут как раз rm замечательно сработает.

> Ото я и говорю -- C:\Program Files\. Мож таки сначала надо понять, почему одни штуковины живут в /usr, а другие -- в /var?

А он /var не трогает, он предлагает /usr раскидать.

int19h (12.08.2004 12:07:14)

Re: Re: Re: что такое "вручную"

> А пакет собрать ну никак нельзя. Видать, за это дают 10 лет с конфискацией...

Можно, но если сборка пакета состоит из ./configure --prefix=/opt/pkg-name && make && make install - жить проще.

int19h (12.08.2004 12:08:27)

Re: Re: Re: Re: Re: Минималистический подход к управлению пакетами в UNIX

>Я не понял, а чем тебя CVS и make world не устраивают?

Патамучта, бл...! За каким уем я должен держать 1) сырцы всего base 2) компилятор на _каждой_ своей машине (которых сейчас 2 десятка: Штаты, Словакия, 4 места в Киеве)? И компилять на каждой. Т.к. base system package'ами не поставишь. А о продолжительности downtime при апгрейде я вообще молчу... Необходимость сделать многое в single при обновлении системы меня убивает -- мне командировки не дают ради апгрейда. А сам процесс компиляния?! Машину загружены по самое нехочу (иначе это не серьезный проект), так я там еще N гигов под /usr/src, /usr/obj, /usr/ports (тоже не маленький) буду держать? И проц жрать компиляцией, когда у меня idle максимум 10%?

Нунах.

Zulu (12.08.2004 12:22:00)

Re: Re: Re: Re: Re: Re: Минималистический подход к управлению пакетами в UNIX

В общем-то согласен, но, только, непонятно - что это там такое интересное при апгрейде base необходимо делать в single?

Ron (12.08.2004 12:29:52)