10 августа 2012 г., 23:40 пользователь Ivan Shmakov <oneing...@gmail.com> написал: >>>>>> Konstantin Fadeyev <jred...@gmail.com> writes: >>>>>> 10 августа 2012 г., 10:17 пользователь Sergey Korobitsin написал: > > […] > > >> Мне кажется, такое имеет смысл только для проприетарного софта, > >> чтобы удобно было таскать по дистрибутивов, не пересобирая (и > >> исходники тащить не нужно, которые могут и не дать). У нас же один > >> дистрибутив, и (я думаю, вы будете использовать stable для всего > >> этого?), и руками поддерживать это всё и накатывать security-апдейты > >> и пересобирать (и тестировать) весь комплект - мне кажется дурной > >> работой. Другое дело, если вы собираетесь сделать эдакий "swiss > >> army knife" для почты и таскать это по (другим) дистрибутивам Linux. > > > Предполагается, что будут использоваться пакеты исходного кода > > которые уже есть в Дебиан и на которые соответственно всё > > вышеозвученное накладывается. То есть будет достаточно просто > > перекомпилировать их с заданными параметрами. > > Нет. > > В случае динамической компоновки, если в используемой целевым ПО > (e. g., Dovecot) библиотеке (e. g., libssl1.0.0) обнаружена — и > исправлена — уязвимость, для устранения уязвимости в системе > достаточно обновить пакет, содержащий данную библиотеку. > > Напротив, в случае статического связывания, потребуется > /вспомнить/ какие из целевых пакетов были статически > скомпонованы с данной библиотекой — в данной (libssl1.0.0), или > одной из прошлых (libssl0.9.8) версий — и пересобрать их. (При > том, что исходный код самих целевых пакетов — не изменился.) > > Также, AFAIK, Debian не предоставляет средств для отслеживания > изменений в «зависимостях» статически-собранных пакетов. (В > отличие от.)
Да всё так, очень сильный аргумент. > > Возможно приведение конфигов в соответствие. Какой-то уровень > > тестирования всё равно придётся проводить, куда ж без этого. > > Замечу также, что, строго говоря, проблемы с любыми > «самосборными» пакетами — вне рамок http://bugs.debian.org/ > (которая представляется значимой частью Debian-инфраструктуры.) > Решать их придется едва ли не полностью самостоятельно. > Да, я это понимаю в общем то и хотелось, чтоб это работало. Но с поправками на мои задачи. Я не говорю о том чтоб писать баг-репорты вызванные моими, эмн, инструментами, а чтоб решение общих проблем производилось более знающими людьми, а я мог этим воспользоваться. > > И да, наверное я хочу этакий универсальный инструмент. И не без > > возможности перемещения между дистрибутивами. Это не является > > основным приоритетом, но я бы хотел решить этот вопрос сейчас. > > Есть подозрение, что решить такого рода задачу помогли бы, > скорее, Nix или Conary, нежели dpkg и APT. > > http://en.wikipedia.org/wiki/Nix_package_manager > http://en.wikipedia.org/wiki/Conary_(package_manager) > Читаю-читаю :-) > На деле, более простым решением может оказаться помещение > «почтового сервера» в дочернюю систему (KVM, Xen, etc.), которая > вполне может быть Debian stable, даже если в качестве основной > системы используется, e. g., NetBSD. > > […] Возможно контейнеры? OpenVZ выпилили, а lxc я почти не знаю. KVM достаточно универсальный выход, но всё же, целая виртуальная машина. > > -- > FSF associate member #7257 http://sf-day.org/ > > > -- > To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/86wr16ejcb....@gray.siamics.net > Не проще ли брать пакеты исходников и компилировать их со своими настройками, пусть и не статически? Чтоб мои программы не пересекались с теми которые идут в дистрибутиве. Или есть инструменты которые позволяют подобное отделение? -- Константин Фадеев
