25 лет команде Альт!

Извини. Передергивать не хотел.

Про удобно/не удобно, у каждого свои предпочтения.

Мне например не нравиться вывод в несколько строк информации о пакете в Ubuntu при apt search [пакет] - не удобно потом фильтровать grep-ом.
Но подробность информации меня при этом радует. Если список не большой, можно глазами увидеть описание нужного пакета.

Везде есть нюансы.

P.S. Но пакетный менеджер всё же нужен.

Мне например не нравиться вывод в несколько строк информации о пакете в Ubuntu при apt search [пакет] - не удобно потом фильтровать grep-ом.

Используй:

apt list ~n[пакет] 

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

откуда брать дату среза репозитория

От балды. Это - исключительно забота пользователя (или администратора сервера обновлений, каковой рекомендуется использовать для Alt).

У меня например установлено 47 пакетов от дебианов 8,9,10, при том что текущий релиз - 11.

Я же не утверждаю что систему управления пакетами невозможно и так вывернуть. Но для этого надо иметь ОЧЕНЬ прямые руки. И я не стал бы делать это где-нибудь в важном промышленном применении. Там всё-таки лучше пересобрать «чужие» пакеты под «свою» систему.

Ну, то есть, по существу тебе ответить нечего. Ожидаемо... :)

А вообще я не понимаю утверждения, что поиск пакетов не работает в Альте.

Те, кто это утверждал, имели в виду что он не работает некоторыми привычными из ДРУГИХ дистрибутивов способами. Да, это так. Но теми способами которые заявлены именно для Альта - работает. Кому хочется что-то еще - всегда могут это добавить и договориться о включении в дистрибутив, благо хозяева Альта охотно идут на контакт. А что касается нынешнего состояния - видимо им, как и их юзерам, хватает того что есть. Вон выше писали что какой-то аэропорт на Альте работает. И ничего, самолёты не падают. Значит достаточно хороший дистрибутив.

А о надобности какой-то сверх-сложной системы управления пакетами (типа того что в NixOS и родственниках) - можно конечно подискутировать. Наверно найдутся и те кому она нужна если ее сделали. Но говорить о массовой потребности в таком уровне сложности лично я бы не стал.

Я конечно не пробовал, но ради интереса полез на сайт NixOS и прочитал про менеджер пакетов NixOS.
Судя по описанию - любую ОС можно превратить в подобие NixOS.

Нашел даже статьи про установку данного менеджера на Alpine и даже на OpenWRT. Я не знаю, можно ли это воспроизвести, но если мои предположения верны, то и на Альте можно программы ставить с помощью данного менеджера пакетов.

Так что это еще один дополнительный способ установки ПО из сторонних репозиториев. Еще один способ в дополнение к уже имеющимся.

Хотя, надо бы попробовать. А то вдруг это тупиковый путь.

и на Альте можно программы ставить с помощью данного менеджера пакетов.

Можно, я пробовал.

Хотя, надо бы попробовать. А то вдруг это тупиковый путь.

Людям с ansible головного мозга должно зайти. Мне лично быстро надоело править конфиг вместо epm install, flatpak install, epm play и прочих.

ansible головного мозга

Как ёмко. Даже добавить нечего.

И это не оскорбление, если что )

Кстааати. Наверняка многие не знают, поэтому не лишним будет написать: для создания воспроизводимых сборок, смешанных библиотек и отката на любую версию чего угодно у альта есть ALT Atomic.

Воспроизводимый образ, OSTree, свой пакетный менеджер apm (никаких apt-rpm!) дистробокс с поддержкой альта, арча и убунты, и флетпаки.

Всё как мы любим :-)

Еще один способ в дополнение к уже имеющимся.

Если он именно «в дополнение» - то это безусловно хорошо. Мало ли вдруг кому потребуется. Главное чтобы такой уровень сложности управления пакетами не навязывался по умолчанию всем как это сделано в NixOS. Ибо очень далеко не всем оно надо, соответственно глубоко вникать будет Лень, а отсутствие «вникания» приведет к дополнительным глюкам из-за «идеологически неправильных» действий. Вон как например с apt-get upgrade выше обсуждалось.

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

Хотя это можно и через ansible повторить.

В общем, не сказал бы что у этого способа много преимуществ.
Просто еще один способ.

Хотя… по идее так можно устанавливать ПО, которого нет в Альте, но есть в NixOS.

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

Получив бесплатный дистрибутив - как-то странно требовать каких-то обязательств. У нас тут свободный софт. Чего-то не хватает - сделайте сами и поделитесь с сообществом.

Я же не жалуюсь что в Дебиане(ну и в Альте тоже) мне не сделали программу для «общения» компа с контроллером управления моей домашней солнечной электростанцией. Разобрался и сам себе сделал. Правда меня хватило только на команднострочную.

И я не очень-то представляю как это вообще можно реализовать. Надо же где-то хранить все версии $packageName, а не только последнюю.

Надо. Весь FHS идёт козе в трещину. Но дело того стоит. Rolling release с возоможностью отката получает лучшее из двух миров. С одной стороны всегда свежий софт (да дебиан, я смотрю на тебя), что отлично работает в 99% случаев. А в том 1%, где нужно, можно откатиться на рабочу версию.

а еще есть Stapler!

Может он - автомобильный мастер-диагност.

Он был старшим научным сотрудником Курчатовского институа в области реакторного материаловедения. И в своей области шарил. Но, сталь это такой хитрый материал, что расчётами там многого не добьёшься. Наука эта экспериментальная, нужно очень много ломать разные железяки при разных условиях, а потом делать минимальный общёт элемента. Так что экселя и ворда из 97-го года вполне достаточно, чтобы обсчитать эксперимент и написать отчёт об испытаниях.

Я пытался людям про R, Latex, literate programming рассказать, на меня смотрели как на безумного.

Stapler это что-то прямо противоположное. Мне кажется. Как в нём сделать воспроизводимую сборку?

да, я имел ввиду локальный кеш.

Кэш — это по определению временное хранилище, которое в любой момент может быть очищено. И никакая функциональность при этом не должна страдать.

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

пакетный менеджер всё же нужен.

Пакетный менеджер - это жизненно необходимая штука в юниксообразных системах где программы не ставятся в отдельный подкаталог, а «размазываются» по всей системе. Без них было бы совсем тяжко. Это «размазывание» я считаю неудачным техническим решением, но ничего не поделаешь - древняя традиция.

Также замечу, что юзеры, приходящие из других ОС, где такого «размазывания» нет, часто недооценивают важность идеологически правильного использования пакетного менеджера. А вот учебников по философии использования пакетных менеджеров как-то маловато. Вот даже здесь, среди опытных юзеров линукса, и то возникли разногласия по поводу apt-get upgrade. Я так думаю это потому что многие не задумываются о способах диагностики корректности состояния как самого пакетного менеджера (его базы данных) так и соответствия состояния этой базы реальному состоянию системы. Хотя инструменты для этого есть. Например в дебиане можно придумать различные тесты с помощью cruft,deborphan,debfoster. Что для этого есть в Альте - увы пока не изучил. Уверен, что названные мной инструменты далеко не единственные и кто-то уже заморачивался корректностью управления пакетами куда больше чем я.

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

Милостью Божьей я с таким сталкивался крайней раз в 2013-м.

важно, чтобы можно было найти человека для поддержки подобной системы.

Это да. Есть проблема. С другой стороны, относительно недавно такой же аргумент использовали и против линуксов вообще. И ничего, как-то удалось сдвинуться с мёртвой точки.

Спасибо, буду иметь в виду.

Наоборот. Информация об окружении не попадает в гит, а из него изначально и берётся.

Как-то вот так это выглядит: https://codeberg.org/tuff-engin/GuixConfigurationSkeleton

Какого чёрта? И даже по твоей ссылке в wiki что в выхлоп с --names-only попадает мусор.

https://packages.altlinux.org/ru/sisyphus/srpms/lua5.1/specfiles/

%package -n lib%{name}-devel
Summary: Embeddable programming language
Group: Development/Other
Provides: %{name}-devel = %EVR
Requires: lib%{name} = %EVR
Conflicts: asterisk-build-hacks < 0.0.2
Obsoletes: asterisk-build-hacks < 0.0.2
Provides: asterisk-build-hacks = 0.0.2

Да, похоже на то. Надо в багу будет отписаться.

Он был старшим научным сотрудником Курчатовского институа

Ну это скажем так более частный случай. Я назвал куда более распространенные.

экселя и ворда из 97-го года вполне достаточно, чтобы обсчитать эксперимент и написать отчёт об испытаниях. Я пытался людям про R, Latex, literate programming рассказать, на меня смотрели как на безумного.

Людей тоже можно понять - они выбрали инструменты, достаточные для их задач и ими пользовались. Выбирали их того что под руку попалось. Потому что вникать одновременно в реакторное материаловедение и в настройку Latex или изучать весьма экзотический язык R - довольно затруднительно. Им бы в компанию хорошо подошел технически грамотный именно компьютерный энтузиаст, готовый не просто «пару раз рассказать», а реально взять на себя технические вопросы поддержки и обучения. Но найти такого человека очень не просто, особенно если это касается такой редкой экзотики как R. Да и сейчас не 90е годы и в атомный институт какого-то «левого» человека просто не допустят даже если он найдется.

У меня лет двадцать назад был случай когда я увидел мучения одного научного сотрудника с набором вручную формул и таблиц в ворде. Так как имел некоторые знания и опыт в Latex то я ему помог - сделал эти отчеты. Но его я естественно не научил ибо талантов к педагогике не имею. А программа, которая обсчитывала данные измерений (магнитные поля), у него была вообще на GWBASIC и постепенно писалась аж с конца 80х годов и существовала в одном экземпляре в одном конкретном месте так как фактически была привязана к уникальному измерительному стенду размером с небольшое одноэтажное здание. Так это всё и существовало четверть века пока тот НИИ не был уничтожен в начале 2010х годов в процессе реформ науки.

Я работал в НИУ ВШЭ и у нас все работы принимались только в LaTeX. И студенческие конференции, и отчёты по практикам, и курсовые с дипломами.

Нижний клапан у студентов помню, горел очень сильно.

даёшь просвещение в массы! одобряю

Вероятно реакция конкретно на «Provides: asterisk-build-hacks».

С моей посторонней точки зрения тут скорее «идеологический» баг разбиения софта на пакеты. Не очень понятно почему язык программирования достаточно общего назначения, коим Lua является, привязан зависимостью к пакету виртуальной «телефонной станции». Никто же не привязывает пакет с gcc к всему тому что этим gcc собирается. На мой взгляд надо выделить в отдельный пакет тот код на lua который к телефонии относится и привязать зависимостью именно его. А не саму библиотеку, используемую для встраивания lua в самые разные проекты. Тогда и не придется в метаданных библиотеки упоминать именно asterisk.

Но это со стороны так ситуация выглядит. Возможно я в своих рассуждениях чего-то не учитываю.

Кстати, когда-то давно,лет двадцать назад, похожий случай встретился в Дебиане. Собирал минималистичную конфигурацию для узкоспецифического применения и обнаружил что пакет с bind почему-то зависит от perl. Днс там был нужен, а dnsmasq то ли еще не было то ли я тогда о нем не знал. Понятно что тащить за собой перл совершенно не хотелось. Стал разбираться почему так. Оказалось, что в пакет с bind закинули какой-то глубоко второстепенный и малонужный буквально одностраничный скрипт для конвертации записей dns из чего-то во что-то. А когда делали пакет - напустили на каталог с файлами некий автогенератор зависимостей. Он увидел скрипт на перле и вписал в жесткие зависимости перл. И никто это не проверил. Вот к чему приводит излишняя автоматизация управления пакетами. В следующем релизе дебиана этот ляп поправили.

С моей посторонней точки зрения тут скорее «идеологический» баг разбиения софта на пакеты. Не очень понятно почему язык программирования достаточно общего назначения, коим Lua является, привязан зависимостью к пакету виртуальной «телефонной станции».

Да там какой-то древний костыль был удаленный почти 10 лет назад: https://packages.altlinux.org/ru/sisyphus/srpms/asterisk-build-hacks/

С определенной осмысленностью предложенного вами сценария применения я могу согласиться. Но вот насчет применения - затрудняюсь сходу сказать в каком случае он может быть нужен. Если это именно упомянутое вами тиражирование, то есть «изготовление» множества идентичных по конфигурации компов - то проще сделать это обычным копированием единожды настроенного. А если компы должны чем-то отличаться - то уже этот сценарий плохо подходит.

В общем, не сказал бы что у этого способа много преимуществ. Просто еще один способ.

Согласен.

так можно устанавливать ПО, которого нет в Альте, но есть в NixOS.

Если бы у меня возникла задача установить чужое ПО то я взял бы исходники и заморочился правильным созданием пакета под используемую мной систему. Тем более если установить надо на более чем один комп. Правильно созданный пакет сильно облегчает дальнейшую поддержку системы куда этот софт будет установлен. Смысла тащить к себе в систему чужие бинарные пакеты я как-то не вижу - при наличии исходников. Минусов этого действия вижу много, а вот какие плюсы - даже и не знаю. Экономия нескольких часов на создание пакета под свою ОС? Сомневаюсь что она оправдана учитывая почти неизбежные будущие проблемы с которыми придется воевать. На мой взгляд это подход в стиле «тяп-ляп и в продакшн». Да, это сейчас модно, но я воспитан на более классической технической культуре.

А учитывая что с хозяевами Альта вполне можно договориться - можно было бы расчитывать и на появление созданного пакета в следующей версии дистрибутива.

древний костыль был удаленный почти 10 лет назад

Тем не менее он откуда-то вылез и сейчас. И версия 0.0.2 а не .1 Мне как-то не довелось иметь дело с asterisk`ом поэтому не могу достаточно компетентно высказаться о [не]нужности этого костыля. Но в любом случае он должен быть связан зависимостью с asterisk а не с lua.

Но в любом случае он должен быть связан зависимостью с asterisk а не с lua.

В любом случае --names-only должен искать по именам только, а не по зависимостям. Иначе это --names-and-requirements-only.

у нас все работы принимались только в LaTeX.

Значит когда-то случайно нашелся компетентный человек, обосновавший выбор правильного инструмента. К сожалению не везде и не всегда так бывает. Нередко выбор программных инструментов оказывается достаточно случайным. А бывает даже что и злонамеренным в чьих-то корыстных интересах, как это в нулевых годах нередко бывало с использованием микрософтовских форматов госорганами например. Вот присылают свои файлы в .doc и как хочешь так и читай. Причем еще и версии регулярно менялись - по мере «освоения средств» на закупках софта. Плохо что статью в УК за вредительство отменили.

В любом случае –names-only должен искать по именам только

Да, меня тоже удивило почему –names-only так работает. Но это по всей видимости баг не Альта, а допущен там где изначально писали «запчасти» пакетной системы. И добиться изменения там - может быть от очень сложно до невозможно.

Он увидел скрипт на перле и вписал в жесткие зависимости перл. И никто это не проверил. Вот к чему приводит излишняя автоматизация управления пакетами.

В ALT такое тоже есть. И есть %add_findreq_skiplist в spec на эти случаи. Но тут человеческий фактор уже только в путь.

Я же написал, что это лишь ещё один дополнительный способ.
Остальные мысли были лишь попыткой оправдать применение данного способа.
Безусловно, вряд ли такое нужно нести в продакшн. А вот в качестве эксперимента, я безусловно попробую.

В любом случае --names-only должен искать по именам только

Так Provides - это дополнительное имя фактически.

Provides - это дополнительное имя фактически.

Согласен. Что еще раз подтверждает мою мысль о желательности отделения этого «hack» от собственно библиотеки lua. Даже если это будет пакет с одним только readme.txt, объясняющим ситуацию, а сам «хак» внутри библиотеки (ну вдруг он там неотделяемый). Всё равно это избавит от нелогичной «обратной» зависимости библиотеки от собственно программы. Обычно-то всегда наоборот - программы зависят от библиотек.

Тогда его надо показывать.

Я же написал, что это лишь ещё один дополнительный способ.

Ни в коем случае не имею никаких возражений.

Остальные мысли были лишь попыткой оправдать применение данного способа.

Вот эти мысли я и осмелился слегка покритиковать. Точнее даже не лично ваши мысли, а саму идею тащить в систему «чужие» бинарные пакеты. Ибо если тащить кое-как по быстрому - то практически неизбежны глюки. А если всё тщательно проверять копаясь в бинарниках - то пересобрать будет как бы не быстрее если это конечно не что-то огромное типа браузера.

Если бы еще тащить предлагалось чужие src-пакеты с последующей их сборкой у себя - это смысл имеет. Ну чтобы не с нуля пакет делать. Хотя если пакет был deb, а нужен rpm - то что-то я не верю в качественную автоматическую конвертацию(как и наоборот).

Если бы еще тащить предлагалось чужие src-пакеты с последующей их сборкой у себя - это смысл имеет. Ну чтобы не с нуля пакет делать. Хотя если пакет был deb, а нужен rpm - то что-то я не верю в качественную автоматическую конвертацию(как и наоборот).

На самом деле речь, в первую очередь, о проприетарщине, для которой доступен только бинарный пакет. Во-вторую о пакетах, для которых сборочной среды нет (Телеграм, например, часто переходит на новейший gcc, который в стабильный бранч уже не попадет). Если же с исходниками всё хорошо, разумеется лучше нормально опакетить.

Согласен. Что еще раз подтверждает мою мысль о желательности отделения этого «hack» от собственно библиотеки lua.

Скорее переделывания зависимости с asterisk-build-hacks на liblua-devel там, где оно используется, c последующим убиранием этого Provides. Наверняка делалось для плавного обновления и, вероятно, давно устарело:

https://packages.altlinux.org/en/sisyphus/srpms/asterisk-build-hacks/

Package removed from sisyphus repository
Removed in the task: #178225
Package removed: Denis Smirnov
Deletion date: Feb. 15, 2017

Да я не про х86 совсем даже. Есть архитектуры, скажем так, гораздо более удивительные.

А вообще мне интересно, как пакет c Undefined Reference сборочные тесты прошёл.

А уж мне-то как это интересно, не пересказать даже.

Там по треду было уточнено, что речь не о х86 и даже не об армах. Там всё куда как веселее.

%package -n lib%{name}-devel

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

Во всём мире принято использовать сокращение «dev» для обозначения разработки - от «development».

И только альтернативно одаренные разрабы поганой альтушки за каким-то деволом используют «devel».

Как результат, это вызывает просто лютую ненависить. Ибо рекомендации из интернетов типа «apt-get install XXX-dev» на поганой альтушке просто не работают! Радость-то какая!

Как бы тебя не огорчить то…

Вот сравни два репозитория одного и того же продукта в двух разных форматах пакетов:

• deb (postgresql.org)
• rpm (postgresql.org)

Вот самое интересное, что твоя цитата:

Во всём мире принято использовать сокращение «dev» для обозначения разработки - от «development».

идет в разрез с действительностью.

Для deb действительно используется сокращение «dev».
Для rpm используется «devel».

Можешь посмотреть репозитории других разработчиков и убедиться в это сам.

АльтЛинукс - это RPM-based Линукс дистрибутив.

Ну а значит сокращение «devel» для него является нормой.

Во всём мире принято использовать сокращение «dev» для обозначения разработки - от «development».

Ахаха

suselinux такой - devel