>FreeBSD Porter's Handbook
>http://www.freebsd.org/doc/en/books/porters-handbook/makefil...
>
>See sections:
>5.2.1 PORTNAME and PORTVERSION
>5.2.2 PORTREVISION and PORTEPOCH Ну прочитал, соглашение для именования deb-пакетов выглядит примерно так же?
PORTNAME_PORTVERSION-PORTREVISION_ARCH.deb
PORTEPOCH нет, потому что версии вроде 20000801 обычно именуются так: 0.0.20000801, так что если разработчик вдруг выпустит версию 1.0, то никакие PORTEPOCH не понадобятся. Если же что-то подобное всё-таки происходит, то выпускают PORTNAME_PORTVERSION-PORTREVISION_ARCH.deb
Но речь _вообще_, _абсолютно_ не об этом. Речь о том, что нет такой замороженной версии портов, затестированной по самое нехочу, где бы только вносились патчи, закрывающие уязвимость пакете. Хочешь закрыть дырку - либо делай патч сам, либо обновляйся из текущей (или стабильной, не суть важно) ветки портов, где повышаются PORTVERSION, а не только PORTREVISION.
Вот в стабильном дебиане именно такая система: если выпущена ветка stable, то PORTVERSION или PORTEPOCH в ней никогда уже не поменяются, будут меняться только PORTREVISION, где каждая ревизия будет закрывать определённую дырку и ничего более. Это даёт мне возможность в течение двух с лишним лет не думать о том, что при очередном обновлении нужно будет поправить где-то конфиг или прогнать какой-нибудь преобразователь базы MySQL в новый формат. Я могу просто поставить пакет cron-apt, настроить его на автоматическое обновление и система будет обновляться без моего участия, а я не буду бояться что что-то сломается и мне нужно будет срочно куда-то ехать, когда я расслабляюсь в отпуске на пляже или лежу после днюхи в дупель пьяный.
>[оверквотинг удален]
>
>ports/net-mgmt/net-snmp/Makefile:
>OPTIONS= IPV6 "Build with IPv6
>support" on
>
> MFD_REWRITES "Build with 64-bit Interface Counters" off
>
>
> PERL "Install additional perl modules" on
> PERL_EMBEDDED "Build embedded perl" on
В пакете perl-modules.
>
> TKMIB "Install graphical MIB browser" off
В пакете tkmib. У этой приблуды ровно две прямые зависимости libsnmp-perl и perl-tk.
> DUMMY "Enable dummy values as placeholders" on
>
>
> DMALLOC "Enable dmalloc debug memory allocator" off
Получается уже насчитали две ситуации, когда Debian гибче?
>[оверквотинг удален]
> ADS
> "With Active Directory support" off
>\
>
> CUPS
> "With CUPS printing support" on \
>
>
> WINBIND
> "With WinBIND support" on \
В отдельном пакете winbind.
> SWAT
> "With SWAT WebGUI" off \
В отдельном пакете swat.
>[оверквотинг удален]
>
> QUOTAS
> "With Disk quota support" off \
>
> UTMP
> "With UTMP accounting support" off \
>
>
> PAM_SMBPASS "With PAM
>authentication vs passdb backends" off \
В отдельном пакете libpam-smbpass.
>[оверквотинг удален]
>
> EXP_MODULES "With experimental
>modules" off \
>
> POPT
> "With system-wide POPT library" on \
>
>
> MAX_DEBUG
>"With maximum debugging" off \
Отладочные символы - в пакете samba-dbg.
>
> SMBTORTURE "With
>smbtorture" off
В пакете samba-tools.
Документация выделена в два отдельных пакета, один из них с pdf-доками. Поддержка монтирования smb-каталогов доступна при установке пакета smbfs, без установки самой samba.
>Так какой из вариантов из factorial(count_options) ты считаешь самым верным для бинарного
>пакета? :)
Факториал - это количество перестановок. В данном случае, если каждая опция может быть только лишь включенной или выключенной, речь идёт о 2^count_options.
>Опционность software - это возможность иметь выбранную функциональность, но это и головная
>боль интегратора.
>Что бы не порождать N-подмножеств портированного software, в Linux-based distribution интеграторы формируют
>некий custom-набор из возможной логики, но не факт, что именно в
>данной ситуации он удовлетворяет техническим и эксплутационным требованиям.
Не факт, но для того, чтобы не ставить или наоборот, поставить swat, мне пересобирать в Debian ничего не потребуется. То же самое и с tkmib. Иногда отключение всего одной зависимости позволяет отказаться от установки ещё кучи всякого хлама. Например установка tkmib потянет за собой иксы. Хорошо, что её устновка отключена в портах, но если программа понадобится - порт нужно будет пересобирать. Не удобно.
>И еще один момент при использовании бинарных пакетов, не технический - мне
>часто встречаются "linux-куул-админы", испытывающие серъезные затруднения при необходимости самостоятельно откомпилировать software from source code, даже при >использовании autotools.
Собрать из исходников - не проблема, проблема - собрать из исходников так, чтобы не засрать систему. Тут нужно либо ставить куда-нибудь в /opt/ (или в /usr/local), либо пытаться собрать двоичный пакет (это идеально), чтобы он обслуживался пакетной системой наравне с остальными программами.
>Остальное, в раздел юмора, по моему, не очень позитивного и конструктивного. Скорее
>мелко-злобного, извини, такое впечатление при чтении. В конечном итоге, software -
>только инструмент человека, повседневный и/или профессиональный.
Да, я специально попытался написать позлобнее, в некоторых местах это была гипербола. Но чтобы люди поняли, нужен шок, иначе всё это пройдёт мимо ушей как какое-то невнятное бормотание.
В том, что software - только инструмент, согласен. Но хороший инструмент позволяет в повысить производительность десятки раз. Когда не думаешь о том, как правильно использовать инструмент, а инструмент сделан так, чтобы его невозможно было использовать неправильно, начинаешь думать не об инструменте, а о цели.
>Возможно, ты встречался не с теми людьми.
Не говорю, что все такие, но как правило среди встречавшихся мне фришников преобладают люди, которые ничего кроме фри и не знают. Отсюда такая злоба по отношению ко всему непонятному.
С другой стороны те, кто фри не знают, ничего плохого о ней не говорят. Кто знает фри и линукс, обычно злится не на саму фри, а на её упёртых фанатиков, которым обычно бесполезно приводить какие-то аргументы в пользу линукса.
