всё наоборот

[netch]

В нормальных юниксах в / и /usr своё системное, в /opt всякие дополнительные пакеты, а в /usr/local то что поставлено руками.
Фряшники заняли /usr/local под порты, и чтобы разнести по разным каталогам (это для лёгкого апгрейда подменой вместе со всеми портами) приходится локальное специфическое ставить куда? Ну естественно, /opt, потому что следующее по рангу среди используемого и даже в $PATH регулярно есть.

Ну не маразм?

NetBSD'шники и то поступили грамотнее - /usr/pkg для портов (pkgsrc на локальном диалекте).

P.S. Смену ${LOCALBASE} не предлагать - и так понятно. И я не про принцип отделения базового состава от дополнительного - это отдельный вопрос. Нет, только про выбранный каталог.

Comments

с чего это ради

[owssrmn.livejournal.com]

из-за перла будет бардак?

Re: с чего это ради

[http://users.livejournal.com/_slw/]

как тебе развлекухапоставить перловый модуль мимо дерева портового перла, в /ADM/perl-куда-то?

Re: с чего это ради

[vitus_wagner]

В приципе - не очень сложно. Симлинку из /usr/local/site-perl в /ADM/perl и вперед.

Re: с чего это ради

[http://users.livejournal.com/_slw/]

А? Какую симлинку?
И смысл?
Разделение по каталогам (вот такое) оно для того, что бы запаковать например /ADM, списать список пакетов и на новой машине поставить пакеты по списку и распаковать /ADM. Можно работать.

Re: с чего это ради

[vitus_wagner]

Смысл в том, что у перла УЖЕ предусмотрено два дерева для модулей - ${PREFIX}/lib/perl5 и /usr/local/lib/site-perl. Соотвественно, если хочется второе из этих деревьев перенаправить на более другую файловую систему, и лень пересобирать перл, то можно обойтись симлинкой, чтобы локальные перловые пакеты лежали там же, где всё прочее локальное.

Re: с чего это ради

[http://users.livejournal.com/_slw/]

ну а нахрен мне второе из этих деревьев сдалось на другой файловой системе?
с кучей-то дарахла от портовых модулей?

Re: с чего это ради

[owssrmn.livejournal.com]

если он есть в дереве портов устраивающей меня версии - не вижу смысла городить огород. если нет - никто не мешает дополнить порты своими пакетами, это не сложно.

это если забыть о том, что фри с перлом общается достаточно нежно. например так.
bsdpan-Compress-Zlib-1.41 Compress::Zlib - Interface to zlib compression library
bsdpan-Digest-MD5-2.36 Digest::MD5 - Perl interface to the MD5 Algorithm
bsdpan-HTML-Parser-3.54 HTML::Parser - HTML parser class
bsdpan-HTML-Tagset-3.10 HTML::Tagset - data tables useful in parsing HTML
bsdpan-MIME-Base64-3.07 MIME::Base64 - Encoding and decoding of base64 strings
bsdpan-URI-1.35 URI - Uniform Resource Identifiers (absolute and relative)
bsdpan-libwww-perl-5.805 LWP - The World-Wide Web library for Perl

это то что поставлено руками из perl -MCPAN -e shell

Re: с чего это ради

[netch]

Ну и зачем ты нагородил этот огород, если оно есть в портах? ;)

Re: с чего это ради

[owssrmn.livejournal.com]

только для того, чтобы показать это славе. я знаю что оно есть в портах :)

Re: с чего это ради

[http://users.livejournal.com/_slw/]

разумеется его нету в дереве портов.
а изучать науку дополнения портов -- в сад.
ну а дальше я начну вспоминать php, сторонние модули к апачу, расширения postgrsql и прочая, прочая

Re: с чего это ради

[owssrmn.livejournal.com]

а дальше мы упираемся в классическую проблему.
afair все хостеры решают ее путем вытаскивания всего джентльменского набора в отдельную ветку и собирают руками весь этот чортов аэроплан (apache,php,my/pg,proftpd e.t.c.)

как раз минимизируя как могут оный бардак.

Re: с чего это ради

[http://users.livejournal.com/_slw/]

те как я и сказал -- как не крутись, а бардак будет