> Простите, а можно пару уточнений? Ну там, например, где и у кого
> они собезъянничали пакетник?Да у всех понемногу. Собственно пакетник получился даже относительно приличный, можете вволю стебать редхатчиков с их кривым бидоноскриптом в роли пакетника. Только радости? "Package manager" depends on "maintainers", "repos" and "policies". Ну то-есть пакетник - это лишь слагаемое успеха, а роялит то экосистема в целом. И вот с этим у бсдюков как-то не того. У них там экосистемой клуб вступайте и канпелируйте, со всеми вытекающими.
> О как. А в нашей вселенной тому же "новому pkg" уже более пяти лет.
Вас послушать - у вас идет цатая пятилтка побед и успехов. Мы не на комсомольской планерке и даже не на скрам-банане. Поэтому маркетинговый булшит и отмазки малоинтересны.
> Да и до этого было чему пакетами ворочать.
Для тех для кого медленно доходит еще раз: никому не интересно как вы формально всех отбреете. Я не ваш менеджер и увольнять вас за плохо запиленую фичу не собираюсь. Но я заинтересован чтобы мне при рулении системой было сухо и комфортно. Что для вас значительно менее перспективно в плане лапши на уши. А то что ваше комьюнити умеет втирать очки я ощутил пару раз на свое шкурке.
> Может, не всегда опримально (тот же текстовый формат для индекса с обратными
> зависимостями не очень подходил), но ...
...но в этом мире никому не интересно кто прошел чекпойнт 15-м и как он лихо обставил 16-го и 17-го (если они были).
> А вот в политике сборки и обновления бинарников в репе произошли нехилые
> такие изменения. Правда, именно с пакетником это не имеет почти ничего
> общего, но то ведь в нашей вселенной.
Это как раз взаимоувязано. Замечательный пакетный менеджер бесполезен без нормальных пакетов и вменяемых политик. И я не очень понимаю: кто будет пакеты майнтайнить в бздах, чтобы они были нормальными? Это в дебиане то с его толпами народа весьма компромиссно, а бзды... вываленый с лопаты выхлоп билдфермы - не синоним нормального пакета.
> Я правильно понимаю, что непонятные религиозные заморочки "если что-то можно сделать с
> помощью великого комбайна^W системд, то поступать иначе великий грех!" запрещают класть
> дефолтные конфиги в (/usr/local)/etc/defaults/foo и перекрывать конфигами в (/usr/local)/etc/foo?
У меня вообще local отсутствует. Зачем он нужен? Я не понимаю этой концепции и не хочу при администрировании трекать ДВА РАЗНЫХ /etc. Мои пакеты имеют в системе столько же прав сколько остальные, отслеживаются пакетником на общих основаниях и вообще. Я получаю штурвал равный майнтайнерскому по возможностям. Мне это удобно и логично. Системд в это вполне логично вписывается: я тоже могу в моем пакете предложить дефолтный вариант старта моей программы, а админ может перекрыть его если считает что это надо делать иначе. С какого дьявола "локальный" пакет должен вести себя иначе нежели "нелокальный"? И зачем мне загаживать мозг такими костылями?
> Все бы хорошо в это аргументации, но вот если использовать то, во
> что многие только едят, по другому назначению, то можно и дойти
> до мысли, что пакетник тут вообще почти не причем.
В данном случае - при чем. Он может принести разумную дефолтную конфигурацию которая работает. Это то чего многие пользователи реально хотят видеть. В идеале установка пакета mediawiki приводит к появлению сервера, который реализует вику. Вбил пару команд (или расставил пару галок) - и уже пользуешься викой. И чтоб сразу работало да еще секурным было. Вот это - современное администрирование и современные требования к нему. А два часа канпелять пых - удел "ветеран юникс админов".
Ну а системд делает такие начинания простым во всем что касается:
- Дефолтного старта сервисов.
- Перекрытия оного админом по вкусу и так чтобы пакетник изменения потом не зашиб.
- Правильного секвенсирования. Если сервису нужна БД - ее надо запустить ДО сервиса. И желательно не клевать админу мозг по дефолту а просто встроить сервис в стартовую последовательность вменяемо. Системд так может: юнит позволяет указать до или после кого его надо запускать.
- Админ может хотеть пять разных инстансов сервиса базы, с разными настройками и вообще в разных загончиках. Системд к такому раскладу готов.
- Системд позволяет серьезно закрутить гайки вплоть до пуска сервиса по сути в контейнере. Только он сам отвесит нужные сисколы в правильном порядек и админу не придется лепить песочницу с кучей либ и прог, а майнтайнер может прямо по дефолту предложить жестко закрученные пермишны в своем пакете.
> Ну разве как запускальщик обработчика "есть новый софт, ести новые конфиги,
> что делать и как быть дальше".
В системд вообще нет канифолинга мозга по этому поводу. По дефолту активен системный вариант запуска и параметров оного из пакета. Админ может перекрыть своим конфигом системный, прописав что он хотел в /etc. А можно устроить inherit системного конфига и поменять два параметра которые в нем не нравились, скостив объем писанины. В обмен на риск что майнтайнеры в новой версии пакета допишут ништяков. Которые не факт что понравятся. А может и понравятся. Зависит от того насколько админ хочет дергать штурвал сам нежели давать его крутить "второму пилоту". В этом случае даже спрашивать ничего не требуется - все разрулено на уровне формализации политик. Админу /etc, системе /lib. К сожалению эту удачную идею не все программы на вооружение взяли и поэтому для остальных конфигов в /etc это несколько более криво и вот там уже могут быть вопросы от пакетника.
Но если я сказал systmctl mask thisdamncrap.service - пакетник может апдейтить пакет как хочет, но "thisdamncrap" больше не будет мозолить мне глаза. Независимо от того как его апдейтили.
> И в том же mergemaster-е лет эдак 18 отлавливали всевозможные возникающие грабли
> и шлифовали процесс обновления конфигов. По крайней мере в нашей вселенной.
Вот вы в этой вашей вселенной и делите там как-нибудь на local и не-local, какие там еще базовые системы и прочий бред.
> Мусью будет так добр и просветит нас в нюансы своей вселенной? Или
> так и ограничится размытыми формулировками "оно плохое, я точно знаю!"
А это практически 100% гарантии - пакетник штука интрузивная и требует пересмотра всех мыслимых вещей от и до. И только тогда им становится комфортно пользоваться. А вы там возитесь с какими-то local. И не забудьте рассказать сколько действий требует отрезать сервис в изолированный контейнер.
> упрощенной сборки пакета из исходников (для авторов или мейнтейнеров) ... как
> то по опеннетно-экспертному, что-ли )
Там вон компании ногами проголосовали за то что им было надо. По-моему у них получилось доходчиво.
> руки растут и не в курсе, что кроме непосредственно пользователей есть
> еще и авторы и мейнтейнеры софта, которым тоже можно взять и
> упростить жизнь и поддержку (особенно, если это ничего не стоит), то
> ... кто же виноват?
Авторы софта в общем случае вообще ничего знать не хотят о дюжине систем и платформ - они пользуются чем им там удобно и как максимум пакетируют под это. В лучшем случае авторы имеют представление о типовых подходах пакетирования и не ломают их. И наверное фрибзда не самая массовая авторская ось с учетом ее общей жёппности как десктопа. Если в системе дров для gpu нет - авторов софта там тоже будет немного. Особенно графического.
Майнтайнеры в фрибсд... ух лол, им столько лет делали "удобно" что те кто хотел именно нормальный пакетник и пакеты видимо свинтили в другие системы. Потому что не МакЛауды. И если уж на то пошло - вот системд для майнтайнеров действительно удобен. Накидать пять строк конфига системде - это не выписыать добавочный скрипт на неком ЯП, здорово отличном от ЯП на котором писалась программа. Особенно когда яп для системного программирования не подходит чуть менее чем нихрена.
