Re: ng_ipacct port

From

Sergey Skvortsov (2:5020/400)

To

Vadim Goncharov

Date

2006-09-19T17:25:04Z

Area

RU.UNIX.BSD

From: Sergey Skvortsov <skv@protey.ru>

On 19.09.2006 16:24, Vadim Goncharov wrote:
>  SS>> Просто не надо простые ситуации экстраполировать в "так надо делать
>  SS>> всегда". И ваше "лучше", подчеркну, если таково для вас, то "не надо
>  SS>> говорить за всех" (с).
>  >> Хехе. Тред начался с того, что был навязываем стиль rc.conf.d, всем, ибо
>  >> предыдущий стиль типа устарел
>  SS> Да, я утверждаю, что стиль монолитного rc.conf устарел. Нет, я его
>  SS> никому не навязываю и не обязываю. Что не мешает для портов, которые
>  SS> поддерживаю, рекомендовать то, что считаю верным и прогрессивным. Нет,
>  SS> эти рекомендации не являются требованиями.
>  SS> Исчерпывающе?
> 
> Не. Когда порт инсталлирует файлы в не ожидаемое место, а куда-то
> в другое, это уже расценивается как требование.

Мда, и какой такой мой порт инсталлирует файлы в "не ожидаемое место"?

Что до ng_ipacct, то самым правильным местом для его конфига является
/usr/local/etc/rc.conf.d. И, пожалуй, в будущих версиях я буду ставить
.sample именно туда.

/etc/rc.conf.d является предпочтительным местом именно потому, что
ng_ipacct - это kernel module. Но это уже моё imho, в rc.subr функции
хотят иначе :) Хотя если следствие, что kernel modules пока что не
идеально ставяться из портов.

>  SS>>>> и т.д.
>  SS>>> Вот кстати ещё свежие пункты:
>  SS>>> * robustness - синтаксическая ошибка в одном конфиге не приведёт к краху
>  SS>>> всей системы (такие коварные ловушки не столь уж редки после reboot'а).
>  >>> :) Синтаксис rc.conf настолько прост, что я ни разу за несколько лет
>  >>> с таким не сталкивался.
>  SS>> Ну я знаю пару случаев, когда забытая кавычка в rc.conf приводила к
>  SS>> остановке загрузки (т.е. ssh конечно обломался запуститься). Типичная
>  SS>> болезнь, когда есть несколько админов у одной машинки. Как этого
>  SS>> избегать, можно не рассказывать, это лишь пример.
>  >> У многих утилит есть режимы проверки корректности конфигов. В том числе
>  >> и тут - sh -n /etc/rc.conf.
>  SS> Вот отличный пример, того, что то, что я пишу не читаете.
>  SS> Я же просил не рассказывать? Поверьте, я в курсе :)
> 
> Я тоже знаю. Я привел то, что вы должны были сказать тем админам, чтоб
> они больше так не делали. А не приводить такие единичные случаи
> в пример общего случая.

Ваша любовь к слову "должны" просто удивительна, особенно с учётом тогоЭ
что максимализм этого слова направлен вовне.

Откуда эти выводы, что я сказал и не сказал этим админам? Разве я просил
ваш "рецепт"? Это навязчивое поспешничество неуместно.

>  >> Я нигде не говорил _единственно_. Это во-первых. А во-вторых, где
>  >> показатели распространенности вашего подхода?
>  SS> Ну сделайте опрос, мне это неинтересно.
> 
> Весь мой круг общения пользуется rc.conf. Что вполне ожидаемо,
> традиционный стиль. Соответственно, доказывать распространенность
> rc.conf.d надо вам.

> Не путайте "для себя", становящееся политикой партии, и "для себя",
> идущее с ней в разрез. Это два разных "для себя".

Ну раз вы считате себя "колеблющимся, но вместе с линией партии"... О
чём тут говорить?

Если же не следите за прогрессом внутри rc.subr - ну так и не надо,
никто не заставляет. Но не читаете man'ы - это уже нехорошо.

>  >>> Конкретно по сабжу - портеры обязаны поддерживать не только 5-ку, на
>  >>> которой в манах ничего об rc.conf.d нет, но и 4-ку, срок поддержки
>  SS>> В манах много чего нет. Читайте исходники rc.subr. И, если хотите быть
>  SS>> конструктивнее, шлите send-pr на hier(7) и т.п.
>  >> Это есть неуважение со стороны портера к конечному пользователю,
>  >> которого тот заставляет делать свою работы - ковыряться в исходниках.
>  SS> Читать исходники rc.subr - задача любого админа, которых хочет понимать
>  SS> как работают startup script и писать свои.
> 
> То есть, ограниченного подмножества админов. А для остальных портер таки
> должен свою работу выполнить.

Что именно? Слать патч на hier? Выложить audiobook с детальным описанием
установки порта? Написать книгу "Ports for dummies"?

Я бы мог понять, если бы ваши претензии относились к коммерческому
support'у по продукту.

Но если админ не читает man'ы и handbook - он недостаточно
квалифицирован, чтобы применять opensource.

Либо это не его профессия, на лесоповал такого, либо на переобучение,
либо пусть покупает commercial support (для FreeBSD такое есть).

>  >> Если уж так надо, то портер и должен был послать патчи на маны.
>  SS> Я вас умоляю, не надо слова "должен".
> 
> Надо, надо. Взялся за гуж - не говори, что не дюж. Его ведь никто не
> заставлял становиться портером, правда? А если уж добровольно взял на
> себя обязанности - так неси их.

Опять "должен". Что ports committer должен, описано в "Committers Guide"
и в "Porters Handbook". Всё что свыше - фантазии и измышления.

>  >>> которой еще не кончился, а система стартовых скриптов там вообще старого
>  >>> стиля.
>  SS>> Что до rc.d скриптов в 4.x - это сплошная головная боль.
>  SS>> B открою по секрету, что поддержка 4.х закончится 2007/01/31, и
>  >> Я знаю и про боль, и про срок. Но если обязательства взяты - их надо
>  >> выполнять.
>  SS> У вас лично ко мне претензии? :)
>  SS> Давайте предметно и по пунктам.
> 
> Ну первое моё письмо к вам поднимите.

Поднял. И?
Из него следует, что вы прочли hier(7), но не прочли rc.subr(8)

Конфиг будет лежать в rc.conf.d, а Карфаген будет разрушен.

>  SS>> "портеры" уже сейчас не поддерживают массу портов. И, конечно, слово
>  SS>> "обязаны" требует разъяснения - приведите точную цитату, даже интересно.
>  >> А если портер не вставил в порт BROKEN= для OSVERSION ниже пятерки
>  >> - значит считается, что он этот порт поддерживает для этой версии,
>  >> потому как сама версия официально поддерживается проектом.
>  SS> Цитату, я просил цитату.
>  SS> Поддержка ОС (security bugfixes) не означает автоматическую поддержку
>  SS> портов.
> 
> В мире опенсорса очень мало писанных правил. Но их с лихвой заменяет
> логика и здравый смысл (а кому-то и мораль). Одним из правил, кстати,
> является POLA. Так вот, если ветка ОС поддерживается, значит будет
> ненулевая база её пользователей, значит логично ожидать по умолчанию,
> что будут работать и порты (а зачем еще ОС тогда в большинстве
> случаев?). А значит, нерабочие порты следует помечать таковыми
> explicitly.

Вы так и не привели цитату. А "логично ожидать по умолчанию" - это очень
слабое звено в силлогизме.

Пожалуйста, применяйте слова "обязаны" и "должен" к себе и, возможно, к
"своему окружению", но не надо говорить за всех, ок?

Масса портеров делает героические усилия, чтобы заставить под 4.x
работать порты, которые уже самими авторами поддерживаются только для
>5.3. Но вот не надо этот утомительный труд вменять им в обязанность.

FYI: для OSVERSION < 500000 принято ставить IGNORE.

>  SS> Многие отсутствующие в 4.х фичи практически нереально
>  SS> пропатчить/сэмулировать в портах.
>  SS> А, к примеру, поддержка perl 5.00503 - это настолько трудоёмкое и
>  SS> бессмысленое занятие, что лично я следующего января жду не дождусь.
> 
> Вы тоже не читаете то, что я вам пишу? Вписывается BROKEN= в порт для
> соответствующей ветки, и всё становится честно, и никаких претензий.

(1) Какое милое "тоже". Нет, я читаю :)
(2) Приведите вопиющий лично для вас пример порта, давно не
собирающегося под 4.х и не помеченного как BROKEN (всякие
alpha/beta-версии мы исключим из рассмотрения).

Я вот смотрю на:
http://pointyhat.freebsd.org/errorlogs/i386-4-failure.html

и нахожу, что число failures весьма мало, особенно относительно общего
числа портов > 15000.

Все ports committers делают свою работу, уж поверьте.

-- 
Sergey Skvortsov
mailto: skv@protey.ru
--- ifmail v.2.15dev5.3
 * Origin: Demos online service (2:5020/400)
SEEN-BY: 50/12 203 400/814 450/159 186 1024 451/30 461/43 132 640 469/999
SEEN-BY: 550/196 4616/3 4625/8 4635/4 4641/444 5000/76 5000 5006/1 5007/1
SEEN-BY: 5010/70 352 5011/13 5012/46 5015/28 5019/31 5020/18 154 175 194 400
SEEN-BY: 5020/545 549 715 758 982 1057 1523 1604 1630 1909 1922 2142 2238 2395
SEEN-BY: 5020/2450 2590 2871 4441 5021/3 29 5022/128 5025/3 750 5026/45
SEEN-BY: 5027/12 5029/32 5030/49 500 556 966 1063 1080 1900 1957 2828 5031/47
SEEN-BY: 5031/70 5034/10 13 5035/3 38 5036/1 5040/47 5042/13 5045/7 5049/1 50
SEEN-BY: 5049/97 5051/15 5054/1 4 8 9 11 28 35 36 37 45 63 66 67 70 75 84 85
SEEN-BY: 5055/95 5057/1 5059/9 5060/88 5061/15 5062/1 10 5063/3 5064/7 5066/18
SEEN-BY: 5074/9 5075/5 5077/70 5080/80 1003 5082/6 5083/21 5085/13 5090/108
SEEN-BY: 5094/4 5095/20 5096/18 5099/11 6001/3 10

PATH: 5020/400 4441 545 5054/1 37