Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 79
Сделайте свой дистрибутив, где будет такой пакетный менеджер.
Да вот всё никак не сподвигну себя на это…
И суть даже не в пакетном менеджере. По моему, нет никакого смысла в персонализировании программы при установке, всё что нужно на самом деле это простые способы, установить/сконфигурировать/выполнить/удалить программу, определённые в стандарте типа FHS или POSIX.
И суть даже не в пакетном менеджере. По моему, нет никакого смысла в персонализировании программы при установке, всё что нужно на самом деле это простые способы, установить/сконфигурировать/выполнить/удалить программу, определённые в стандарте типа FHS или POSIX.
Под персонализированием, я не use-флаги имел ввиду, а именование каталогов манер human-friendly для размещения частей программы — по, большому счёту, не нужно. А нужен единообразный, унифицированный подход к размещению/конфигурированию/удалению программы, подобный тому, который применяется при запуске/завершении программы…
Не устраивают тем, что все они напоминают басню Крылова «Лебедь, щука и рак».
А устроило-бы программиста, скажем, появление различий в способе fork'а процесса, допустим в debian и redhat?
Да, форматы пакетов это не fork, но и почему бы не быть разным форматам. Да и всё многообразие пакетных систем вполне может существовать, главное что-бы они выполняли одно и тоже пользуясь одними и теми же вызовами для развёртывания программы в одних и тех же местах файловой системы. И пользователю надо смотреть не на места размещения программы и её компонент, а на программу и всё что к ней относится. Для пример взгляните на отношение ip и dns:
ip — структурирует
dns — human friendly
А если таким же образом представить программу в системе:
07f51c01-9811-4ab2-b905-d8e3a8a750b7 <-> gimp
gimp:configs
gimp:libs
gimp:docs
gimp:brushes
?
И я не затрагиваю windows/mac, речь о linux.
ip — структурирует
dns — human friendly
А если таким же образом представить программу в системе:
07f51c01-9811-4ab2-b905-d8e3a8a750b7 <-> gimp
gimp:configs
gimp:libs
gimp:docs
gimp:brushes
?
И я не затрагиваю windows/mac, речь о linux.
Ну в статье я вроде-бы дал понять — хорошо-бы искоренить существующий разброд и шатание в области управления размещением программ. Не факт что всё должно быть именно так, как я сказал. Не факт что вообще, что-то должно меняться. И может быть всё просто будет эволюционировать, пока не выживет сильнейший. Но по мне так сегодня костылизм в этой области растёт — костыль, косылём погоняет (puppet, chef > apt-get, yum, emerge)…
Спасибо, но о equery f и о qlist вкурсе ;)
Спасибо, но о equery f и о qlist вкурсе ;)
Сейчас это мнимое «многообразие» содержит Debian, Ubuntu, Redhat, Centos, SuSe. Причём реально у нас есть всего три пакетных менеджера, с прописанными в них правилами установки.
Может быть, Linux Standard Base то что Вам понравится?
Может быть, Linux Standard Base то что Вам понравится?
Все уже украдено до вас. Дистрибутив с подобной пакетной системой вполне себе существует. Мне более симпатична идея которую предлагают использовать в Haiku. qube.ru/articles/kratkij-obzor-upravlenija-paketami-v-haiku
Поздравляю, вы изобрели макось. Теперь Apple подаст на вас в суд.
А если еще проще проще сделать:
/???/someprogram/(etc|bin|var)
/bin/
В итоге только удаляем /???/someprogram, а потом все линки из /bin/, которые сиротливы.
А вообще эту странную традицию bin и usr/bin уже давно пора прекращать. Всего лишь из-за того, что когда-то кому-то не хватило ленты магнитной…
/???/someprogram/(etc|bin|var)
/bin/
В итоге только удаляем /???/someprogram, а потом все линки из /bin/, которые сиротливы.
А вообще эту странную традицию bin и usr/bin уже давно пора прекращать. Всего лишь из-за того, что когда-то кому-то не хватило ленты магнитной…
www.gobolinux.org/index.php?page=at_a_glance
Как-то так.
Как-то так.
Проблема в том, что папочки /etc, /bin, /usr, и прочие некоторые люди любят растаскивать по разным разделам.
Они не почему-то не поймут вашей красивой идеи!
Они не почему-то не поймут вашей красивой идеи!
Нахрена делать велосипед когда уже есть тебе deb и rpm и обвязка сверху yum apt?
Мне кажется я совсем не понял смысла статьи.
Мне кажется я совсем не понял смысла статьи.
Поддерживаю идею про «изобрести МакОсь». Когда я узнал что в МакОС программы существуют в виде одной единственной иконки, я просто обалдел. Долго тряс головой и гадал почему никто больше до этого не додумался.
А когда я потом узнал что эта «иконка» на самом деле tgz (ну или какой-то еще) архив, содержащий привычную структуру каталогов — так и вовсе рвал волосы на всех местах.
Ну почему бы не придумать для линукса очередной слой абстракции ФС, чтобы он для каждого запущенного из такого файла-архива процесса отображал структуру каталогов на /
А снаружи мы бы имели один маленький файлик, который можем положить куда нам угодно, и оттуда запускать.
Может быть для мелких unix-way утилит это было бы неудобно, а вот для графических программ — очень даже.
А когда я потом узнал что эта «иконка» на самом деле tgz (ну или какой-то еще) архив, содержащий привычную структуру каталогов — так и вовсе рвал волосы на всех местах.
Ну почему бы не придумать для линукса очередной слой абстракции ФС, чтобы он для каждого запущенного из такого файла-архива процесса отображал структуру каталогов на /
А снаружи мы бы имели один маленький файлик, который можем положить куда нам угодно, и оттуда запускать.
Может быть для мелких unix-way утилит это было бы неудобно, а вот для графических программ — очень даже.
Тогда уж что-то вроде /dist/{did}/, который будет корневой директорией для программы и симлинки на все файлы и директории в нужных местах. Набирать какой-нибудь cd /var/07f51c01-9811-4ab2-b905-d8e3a8a750b7/db совершенно не хочется.
Рассказываю как это у нас:
во-первых пакеты, во-вторых мета-пакет с версией. Пакеты пушатся с билд-сервера на сервер с приватным репозиторием, когда туда пушится мета-пакет, то во время upgrade обновляются все депенденсы. Если какая-то версия начинает/перестаёт депендиться от других пакетов, они сносятся/устанвливаются.
во-первых пакеты, во-вторых мета-пакет с версией. Пакеты пушатся с билд-сервера на сервер с приватным репозиторием, когда туда пушится мета-пакет, то во время upgrade обновляются все депенденсы. Если какая-то версия начинает/перестаёт депендиться от других пакетов, они сносятся/устанвливаются.
/usr/bin/<did>/program
А значение $PATH не превысит потом максимальную длину переменной окружения?
Извините, а зачем убирать систему управления конфигурации, пакетный менеджер и скрипты установки, а затем жаловаться что нету системы управления конфигурации, пакетного менеджера и скриптов установки?
А вы задумывались почему существует несколько разных пакетных менеджеров? Наверное потому, что вышеозвученная проблема не так тривиальна как кажется на первый взгляд. И каждый из авторов пакетных менеджеров решил ее в силу своих знаний и возможностей.
Скорее опираясь на свои предпочтения и видение данной проблемы.
Да, задумывался. И проблема действительно не так проста, как кажется. И ключевая часть вашей фразы к пониманию, того о чём я говорю — «каждый из авторов пакетных менеджеров решил» — городить свой огород, вот тут и вспоминаем басни Крылова.
А чем /opt не угодил?
Таков хабр: задаёшь вопрос автору, ответа не получаешь, зато получаешь минусы от проходящих мимо.
Поясню свой комментарий: автор говорит, что
и внезапно от этой конкретной проблемы переходит к вопросу «как нам обустроить Линуксы». Предлагается по-прежнему раскидывать файлы по всей ФС, но с префиксом.
Между тем, существует стандартный /opt: www.pathname.com/fhs/2.2/fhs-3.12.html. Программа ставится в подкаталог /opt и удаление её сводится к rm -rf /opt/program_name. Для простого доступа к бинарникам можно делать симлинки в /opt/bin или /usr/bin. Что может быть проще?
Поясню свой комментарий: автор говорит, что
Допустим я сумел разобраться в том, где должны размещаться части программы, создал нужные каталоги, скопировал файлы, обновил окружение и программа теперь успешно выполняется.
Но прошло время, мной уже давно забыто где и как размещались компоненты программы
и внезапно от этой конкретной проблемы переходит к вопросу «как нам обустроить Линуксы». Предлагается по-прежнему раскидывать файлы по всей ФС, но с префиксом.
Между тем, существует стандартный /opt: www.pathname.com/fhs/2.2/fhs-3.12.html. Программа ставится в подкаталог /opt и удаление её сводится к rm -rf /opt/program_name. Для простого доступа к бинарникам можно делать симлинки в /opt/bin или /usr/bin. Что может быть проще?
Извините, но на всех не хватает, да и чадо в приоритете ;)
Речь даже не столько о том где размещать (пусть это будет /opt или что ещё), а о том как побудить дистростроителей к унифицированному размещению/конфигурированию/удалению программы. И в этом ключе было-бы неплохо узаконить в POSIX соответствующие вызовы, imho.
Речь даже не столько о том где размещать (пусть это будет /opt или что ещё), а о том как побудить дистростроителей к унифицированному размещению/конфигурированию/удалению программы. И в этом ключе было-бы неплохо узаконить в POSIX соответствующие вызовы, imho.
А зачем? Здесь тоже действует естественный отбор и в конечном итоге выживает кто-то один. Так было с pulseaudio, так происходит с systemd и рано или поздно так случится и с пакетным менеджером.
Возможно. А возможно и нет. Возможно так и будет существовать зоопарк самых разных способов установки программ, если не предложить какой-то общий, более продуманный подход.
Сейчас он является стандартом де-факто. Придёт время и его вытеснит какой-нибудь очередной klang.
Рекурсии ради — мнение Ъ-линуксоидов по этому поводу: www.linux.org.ru/forum/talks/8285744
Позвольте задать Вам некоторые вопросы…
- как вы собираетесь «разруливать» системные зависимости?
- вам не кажется, что ETC-каталог будет загажен, а PATH перегружен?
- вы уверены, что не нарушите целостность системы?
- это видимо блобы?
- как вы собираетесь поддерживать зоопарк платформ?
- пока не знаю
- место размещения не приницпиально, в том же nix, например, создаётся /etc/nix/ остальное симлинкается
- с чего друг это должно нарушать целостность?
- а что с блобами? Не понял вопроса.
- сейчас речь не идёт о поддержке зоопарка, но какие вы тут видите проблемы?
место размещения не приницпиально, в том же nix, например, создаётся /etc/nix/ остальное симлинкается
Не принципиально, да. Можно создать каталог, в нем уже держать все. И заметьте он должен быть еще и human readable по возможности. Только в etc симлинки большая редкость и по видимому разработчики стараются их избегать.
Вообще etc не лучшее место для таких задач. Уж лучше var.
Знаете ли у меня и так $HOME забит тем что я не создавал никогда. Уж лучше писалось все в папку ~/.etc Но это побочный эффект базарной модели. С этим можно бороться, благо все открыто.
с чего друг это должно нарушать целостность?
Если Вы решаете только задачу установки своих пакетов, то вроде ничего страшного не произойдет. Но ведь пакет будет использовать обще-системные библиотеки (уже установленные) Что будете делать если понадобится версия определенной библиотеки, а в системе другая? Правильно Ваш пм поставит свою. Здравствуй целостность. Другой путь: вам придется держать копии библиотек на все случаи, не затрагивая системные. Приложение в свою очередь захочет системных, а в системе не те. Свою программу вы еще как-то сможете утсановить, если знаете ее зависимости. Но с остальными придется перекомпилять с заменой всех путей. Здравствуй Гена! Если вы будете играть по правилом системы, то придется считаться с установленными пм. Играть по их правилам.
а что с блобами? Не понял вопроса.
сейчас речь не идёт о поддержке зоопарка, но какие вы тут видите проблемы?
Это следствие предыдущего вопроса. Вам нужно будет таскать с собой кучу библиотек которые уже, возможно есть в системе. Вы же не будете рассчитывать, что нужные библиотеки уже стоят. Вы просто поставите те-же но свои. Здравствуй обновления безопасности в системе. Админ не забудь пополнить запас пива и бутербродов! Вы ведь будете таскать эти библиотеки в виде binary blobs? Здравствуй место на диске!
Про зоопарк. Вы собираетесь только одну платформу/разрядность поддерживать. Вы будете это все сами компилять для деплоя и обновлений? Или предложите пользователю выбор i386|amd64?
Совету вам поисследовать ОС Darwin на iPad через ssh. И потом задаться вопросом почему это в iPad (и других продуктах этого клана) у приложений папка «Документы» своя и почему нужны некоторые манипуляции для обмена этой информации между приложениями. Почему, пользуясь программой просмотра PDF, довольно сложно в другом приложении получить доступ к этим документам?
Что Вам мешает написать ebuild и передать его мантейнерам пакетов или стать самому им?
Спасибо, за развёрнутый ответ, но всё же какие-то надуманные проблемы названы, а про блобы я так и не понял, как и не понял причём тут ebuild'ы.
Да я тоже зато, что-бы был ~/.etc (хотя уже есть ~/.config и ~/.local).
Что касается зависимостей и системных библиотек, в gentoo есть slot для этого, в nix ос ещё и снапшоты всего состояния, что до чудных программ требующих например устаревшую системную либу — побоку, или применять для них chroot или подход типа как в Qubes.
И по поводу зоопарка — какой именно предпочту (если вообще предпочту) вариант не так уж и важен, можно например сделать так, как это делают сегодня те же разработчики nixos использующие свой билдсервер hydra. Qubes
Или это всё причины по которым под программу не стоит выделять ID?
Да я тоже зато, что-бы был ~/.etc (хотя уже есть ~/.config и ~/.local).
Что касается зависимостей и системных библиотек, в gentoo есть slot для этого, в nix ос ещё и снапшоты всего состояния, что до чудных программ требующих например устаревшую системную либу — побоку, или применять для них chroot или подход типа как в Qubes.
И по поводу зоопарка — какой именно предпочту (если вообще предпочту) вариант не так уж и важен, можно например сделать так, как это делают сегодня те же разработчики nixos использующие свой билдсервер hydra. Qubes
Или это всё причины по которым под программу не стоит выделять ID?
про блобы я так и не понял, как и не понял причём тут ebuild
Это самый важный момент во всей этой истории. Вы похоже не хотите понять или делаете вид что не понимаете о чем речь. Вы не знаете что такое ebuild? Что-то гентушники не особо слоты юзают. Мне лично понятно почему. Здравствуй eselect. Получается, вы допускаете установку либ в систему раз говорите про слоты и игнорируете штатный пм со своими слотами? Как результат подмена системных либ без уведомления штатной системы. Знаете как это называется?
Если вы разрабатываете пакетный менеджер универсальный, то так и говорите. Но вам тогда еще нужно сделать свой дистрибутив или считаться со штатными пакетами или ни то ни другое, а бинарные сборки в своей песочнице не пересекающиеся с системой.
Как вы собираетесь деплоить пакеты в том числе и свой ПМ?
Из исходников или из откомпиленных binary?
надуманные проблемы
Это Вам так показалось. Это одна из основных причин, когда пользователи принимают решение перейти на *nix… Эти проблемы самые важные для любой системы: системная целостность, развертывание, обновление, чистота системы, дисковое пространство, удобство администрирование, безопасность.
Это вы где такому научились считать, что данные проблемы не существенны? Или это Ваши убеждения от приобретенного опыта?
Или это всё причины по которым под программу не стоит выделять ID?
Хотите реестр установленных пакетов поверх штатного — для начала создайте свою ФС с поддержкой ID-логики. Все уже есть — лучше сделайте генератор ebuild-ов и форматов пакетов, совместимых со штатными пм.
Если вы решаете задачу «само-продвижения» своих бинарных сборок, то имеет смысл делать узко-заточенный установщик для деплоя своих пакетов, но систему не ТРОЖЬ! Бинарные сборки никто в здравом уме не будет ставить в систему, если только в песочнице. Никто с этим возится не будет. Вы ведь не собираетесь предоставлять исходный код пм и устанавливаемых пакетов с хэшами и контрольными суммами?
Теперь понятно о чём Вы толкуете.
1) пока не делаю пм
2) предлагаю внедрить единый стандарт на функции для развёртывания пакетов
3) предлагаю либо создать пм, который будет использовать эти функции, либо поддержать эти функции в существующих пм
4) я против того, что-бы развёртывание производилось более чем одним пм в пределах дистрибутива.
5) ebuild/rpm/deb — не принципиально как будут они парситься и компилироваться, важно что-бы в конечном итоге установка проходила единообразным образом вне зависимости от дистрибутива.
1) пока не делаю пм
2) предлагаю внедрить единый стандарт на функции для развёртывания пакетов
3) предлагаю либо создать пм, который будет использовать эти функции, либо поддержать эти функции в существующих пм
4) я против того, что-бы развёртывание производилось более чем одним пм в пределах дистрибутива.
5) ebuild/rpm/deb — не принципиально как будут они парситься и компилироваться, важно что-бы в конечном итоге установка проходила единообразным образом вне зависимости от дистрибутива.
1) пока не делаю пм
А что это? Setup.exe? Это не пм, это другое но пакеты ставит. Есть такой проект: ставит все в одну папку и запускает. Похоже вам такое надо. Но без рутовых прав. Это может вам помешать, полагаю.
2) предлагаю внедрить единый стандарт на функции для развёртывания пакетов
не будет такого никогда. Как говорится «Не дождетесь» (с)
Помните как у классиков: «проект о введении единомыслия в России...»
4) я против того, что-бы развёртывание производилось более чем одним пм в пределах дистрибутива
Это переводится так: «что люди только не делают чтобы не пользоваться штатным пм».
В общем не понятно, зачем вам все это…
установка проходила единообразным образом вне зависимости от дистрибутива
Это миф и единомыслие. Если хочется тотальности — пилите свой дистр. Может когда нибудь все увидят как надо и ринутся делать так-же. Только вам придется убедить в этом ту часть 1-2% пользователей…
Вы видели насколько разные идеологии установщиков в разных дистрах? Это нормально и правильно.
А отчего тогда нет разных идеологий в плане fork()? Всё-таки FHS, POSIX существуют и их успешно придерживаются.
Потому-что это API, регламентированное общепринятыми стандартами. В свою очередь установщики это уже то, что живет в этих системах, не нарушая ее идеологии. Если бы были жесткие стандарты на все, то система перестала бы развиваться или была бы система ради системы. Стандартизируются так сказать интерфейсы, но не реализация. И это правильно — залог развивающейся системы.
вот и я предлагаю стандартизировать интерфейс…
вот и я предлагаю стандартизировать интерфейс…
Вы определитесь для начала, чем интерфейс отличается от реализации.
Для установки и удаления одной программы достаточно штатных средств. Если не устраивает, пользуйтесь другой платформой и скорее всего коммерческой. Например от Apple. Решения для *nix в основном открытые и в них задействовано много людей. Чтобы что-то «протолкнуть» свое, надо убедить это сообщество или играть по сформировавшимся правилам.
Если Вы считаете нормой установку несколько пакетов одновременно, то это проблема не пм или layout — это Ваша проблема. Это не нормально, когда нужно несколько версий одновременно. Можно перечислить практически все случаи, когда это необходимо.
Читали статьи наверное про философию простых решений?
Например эту?
pixelstech.net/article/index.php?id=1336304966
… так, что поставьте вентилятор и пусть он выдувает пустые коробки а на орбите пользуйтесь простым карандашом, вместо гелиевой супер-ручки.
Извиняйте за прямой вопрос, но Вы это для себя делаете лично или выполняете чей-то заказ? Вам не кажется, что это все делает Вас «крайним»?
Вы определитесь для начала, чем интерфейс отличается от реализации.
Трололо?
Для установки и удаления одной программы достаточно штатных средств
Вам, достаточно.
Если не устраивает, пользуйтесь другой платформой и скорее всего коммерческой.
Я, как нибудь, без посторонней помощи решу, чем мне пользоваться.
Решения для *nix в основном открытые и в них задействовано много людей. Чтобы что-то «протолкнуть» свое, надо убедить это сообщество
КЭП?
или играть по сформировавшимся правилам.
Не факт и не правило.
Если Вы считаете нормой установку несколько пакетов одновременно, то это проблема не пм или layout — это Ваша проблема.
Ага, «ручной труд — облагораживает»… :facepalm:
Это не нормально, когда нужно несколько версий одновременно.
И Вы тоже заметили, что мир не идеален?!
Можно перечислить практически все случаи, когда это необходимо
Да. И именно. Это бывает необходимо.
>Вы это для себя делаете лично...? Вам не кажется, что это все делает Вас «крайним»?
Да (но для многих). Не кажется.
Про KISS смотри UPD (на многие вопросы есть ответы в лоровской ветке ссылка в UDP).
«Простой карандаш» на орбите был не «простой», а восковой, и space pen заюзали и американцы и русские. Меньше на мифы ведитесь.
А я не планирую. Я говорю о том, что сейчас ситуация с установкой ПО в Linux — «кто в лес, кто по дрова». И если даже прикинуть, как скоро это решиться в обозримом будущем без стандартизации, то можно просто развести руками и припонять плечи.
А я вот хочу пакетный менеджер в стиле homebrew и macports, когда программы ставятся в собственную изолированную клетку, а в основную FS отображаются через хардлинки(симлинки). Это автоматически создает механизм слотов если пускать прогу из клетки и делает легким и простым переключение между версиями.
пакетный менеджер nix подобным образом работает.
а я, вот, например, не хочу, чтобы были пакетные менеджеры, которые кладут болт на shared libraries и таскают с собой 100500 миллионов копий одних и тех же библиотек.
Откуда вдруг мысль, что шаред идут лесом в случае с наличием id у пакета?
Причем тут это? Ну будут тебе симлинки на нужные версии либ в /usr/lib64 а также на нужные версии либ в /usr/lib32, а сами либы для нескольких версий софта будут лежать себе в клеточке.
Это лишь допиленый механизм слотов в Генте.
Это лишь допиленый механизм слотов в Генте.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Deploy-ные костыли или пироги с «сюрпризом»