О портах и пакетах

[filonov]

Поскольку тема вызвала широкий резонанс
обобщу свое мнение.

1. Существенная часть претензий от линуксоидов с BSD-шной системе портов, сводятся к тому, что FreeBSD - не Linux. С этим ничего поделать нельзя, да и не стоит оно того imho. Изготовление очередного линуксоклона FreeBSD попросту добьет.
2. Система портов-пакетов безусловно нуждается в значительной

Comments

Модули

[ext_732967]

Модули в пакетах - это хорошо и полезно. Но есть некоторые факторы, которые сильно этому мешают:
1) сложность(?) внятной реализации в рамках существующей системы портов. При чем сложность как со стороны допиливания bsd.port.mk, так и сложность для мейнтейнеров портов.
2) необходимость переработки существующего формата базы пакетов. Неплохо было бы сделать нормальную shared library для работы с пакетами, ибо сейчас "либа" вроде как и есть, но на самом деле это просто несколько файлов кода, которые линкуются прямо в pkg_*
3) тотальная лень. Лень мейнтейнеров что-то переделывать и разбираться с модулями. Лень разработчиков переделывать все без лишних костылей.

Мне кажется что систему построенную на костылях и подпорках^W^W^Wmake пора выбрасывать, но у меня нету никаких предположений чем ее можно заменить.

Re: Модули

[filonov]

1) Со стороны bsd.port.mk - да, поразвлекаться придется знатно. Со стороным мейнтейнеров - все не так однозначно. Часть портов просто исчезнет, избавив мейнтейнеров от головной боли. Например сейчас в дереве 77 php5-* портов. С модульной системой, все что входит в сырцы самого пхп схлопывается в 1 порт.

2) т.е. необходимо внятное API. согласен. Формат пакетов также надо менять. Ибо цифровую подпись в нынешних пакетах просто некуда совать.

Re: Модули

[ext_732967]

Да подпись в пакет запихнуть - не проблема. Просто отдельный файл +SIGNATURE внутри tbz2, или отдельный файл сбоку. Проблема допилить их проверку и сделать нормальную инфраструктуру сертификатов.

Re: Модули

[filonov]

Просто отдельный файл +SIGNATURE внутри tbz2
а как ее проверять потом? Подписывается то файл без подписи.

[akela_wolf]

Хм... А что добавляют модули, если они по сути отдельные порты? Apache 1.3 и Apache 2.0 - по сути отдельные проекты, каждый со своими исходниками... PHP в качестве модуля собирается под каждый из них отдельно. Допустим, установив php модулем для apache13 я уже не могу безболезненно удалить apache13 и поставить apache20 или apache22 - нужно пересобирать модуль PHP.

Другое дело что у PHP может быть выбор - под какой апач собирать модуль (не обязательно, кстати, под тот что установлен в систему) т.е. можно собрать php+apache13, php+apache20, php+apache22 пакеты и выбирать какой именно устанавливать (конечно, при этом проверится зависимость что апач нужной версии присутствует в системе)

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

PS. "набор инсталлируемых пакетов задается при инсталляции модуля" - наверное должно быть "набор инсталлируемых модулей задается при инсталляции пакета"

[filonov]

По сути это то же самое разбиение одного порта на множество, только оформленное в виде частей одного и того же порта (модулей), а не отдельных портов.
Оно более логично вытекает из существующего процесса разработки.

Другое дело что у PHP может быть выбор - под какой апач собирать модуль (не обязательно, кстати, под тот что установлен в систему)
Оно апачевые потроха хочет. так что задача собрать под неустановленный апач - весьма нетривиально.

"набор инсталлируемых пакетов задается при инсталляции модуля" - наверное должно быть "набор инсталлируемых модулей задается при инсталляции пакета"
спс

[akela_wolf]

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

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

[filonov]

Никакой магии - нужный апач установится по ходу дела во временную директорию, а затем будет вышвырнут нафиг после получения требуемого модуля php.
Угу. а потом выяснится, что кто-то где-то вкомпилировал полный путь.

[filonov]

А в чем собственно проблема?
бинарник один. Он предоставляет модули exim.mysql или exim.sqlite или и то и другое в зависимости от параметров сборки.

[filonov]

C чего им быть разными, если бинарник у exim'а один.

[stanislavvv]

Хм... У пакетов .deb, к примеру, есть свойство Provides.
Например для пакета apache2-mpm-prefork прописано следующее:
Provides: apache2, apache2-mpm, httpd, httpd-cgi

При этом от этого самого Provides вполне могут быть зависимости.
Так что не вижу смысла дробить пакеты еще сильнее.
Достаточно продумать метаинформацию о пакете.

[filonov]

Дебиановское provides рудиментарно, но в том же направлении.
И сам апач и текущие портовые options предоставляют гораздо больший выбор.