Идеальная пакетная система.

Gentoo, Nixos?

Рач, дебиан.

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

Никогда.

Насильственного обновления частей системы для удаления программ?

Это как вообще?

кстати да, слышал исключительно хорошие отзывы о Guix.

Наверное, что-то в списке лишнее, случайно попавшее из devscripts

...а так же дублирующиеся программы и программы, нужные только понимающим людям (это не ты, конечно). В общем, слишком толсто.

При наборе apt-get install package он показывает то что должно быть установлено, а это приводит к обновлению. Какая-то замена наверное.

Посмотрю!

ответ в советском стиле: на данный момент в отраслевых дистрибутивах таких технологий нет.

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

они и так его меняют в 20 раз чаще проприетарщиков. хуже точно не будет.

А при чем здесь маководы? Под OS X есть homebrew

Однако, по честноку сказать предпочитаю все же качать бинарники с офсайтов, т.к.: 1) там свежее и обновляются чаще; 2) ffmpeg в репозиториях без эксперементальных кодеков и всех последних фичь.

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

Концептуально я за вариант 2. Мне не нравится что в юниксах помойка когда все либы в /lib, все бинари в /bin... Но, возможно, плодить отдельные папки (кто-нить обязательно вспомнит про Program Files) и кучи симлинков это оверкилл... Зато можно легко держать несколько версий одного пакета. Для всяких питонов для этого нагородили virtualenv, но было бы неплохо иметь общесистемное средство.

По сути пакетник удобен только если нужно что то собирать с кучей зависимостей

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

С адом не встречался. Мой пакетный менеджер (альтовский apt/rpm) няша и не дает мне разбомбить систему.

Ну а я так не умею - вот скачал исходники Doom3-bfg посмотрел что нужно ему установил пакетником и сконпелял. Как по другому то?

Как в винде надо или в андроиде.

Я думаю к этому в итоге и придут.

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

получите свой школьный линукс и распишитесь! потом их станет больше и никакой анонимус уже не спасет!

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

Будет, поверь.

Блин, виндузятники и маководы рассуждают о том, как должна выглядеть пакетная система Linux. Дожили.

Коллозии

Марш к логопеду!

Я не такой уж виндузятник.
И не вижу ничего плохого во второй системе на симлинках. По сути тот же пакетный менеджер.

Короче, я тут пофантазировал, вот что получиилось:
В /opt/ лежат папки с категориями пакетов, в этих папках лежат папки уже с названиями пакетов, а там — ссылка на один и тот же универсальный скрпт, который устанавливает пакет по имени директории, в которой лежит (если ему не передать дополнительный параметр. Также скрипт может получать дополнительные инструкции, которые идут в комплекте с бинарным пакетом (если нет бинарника, то с исходниками). Скрипт будет называться, к примеру, pkgscipt, а оригинал будет храниться в /etc/pkg/pkgscript (его можно изменить) и конфиг для скрипта в /etc/pkg/pkgscipt.cfg. Для того, чтобы назначить полностью свой скипт для установки скрипта, нужно в папке пакета создать скипт pkgscript.custom. Пакетный менеджер будет тесно взаимодейтвовать с pkgscipt (если речь идёт об установке или удалении пакетов), а также добавлять и изменять репозитории, устанавливать разные версии пакетов (при установке пакета в его папке будет появляться директория, с названием в виде текущей версии, таких папок может быть несполько) и обновлять систему, производить более тонкие операции с пакетами. Собственно, в папки типа /lib/, /usr/, /bin/ и т.д. файлы пакета копироваться не будут, вместо этого будут создаваться ссылки на эти файлы (эти ссылки будут удаляться,если удалён оригинал, такое можно реализовать, к примеру, с помощью демона), которые будут все храниться в папке пакета. Это позволит намного легче опакечивать то, что нужно собирать через make и устанавливать через make install. Также можно будет не заморачиваться с удалением пакетов.

Правда, это преимущество сводится на нет криворукими мейнтейнерами. Перешёл я тут, значит, на 5 плазму и что? Я вынужден терпеть то, что пакетник ставит мне дрова на amdgpu которых у меня никогда не было и врядли когда будут. И nouveau за каким-то. Попытка удалить это ненужно заканчивается конфликтом зависимостей: это ломает то, а это вот это. Тут нужен полный reset культуры упаковывания пакетов.

А дистрибутив какой ?

Что за дистрибутив? Школьников нельзя пускать в мейнтейнеры.

Windows side-by-side. Хранит все версии библиотек, которые тащатся в систему разным софтом и подсовывает эти библиотеки этому софту. Из-за этого система жиреет.

Кубунта 15.04. На lts как-то попроще было. Четвертокеды вылизаны от души. Но любопытство взяло верх и do-release-upgrade.

А я вижу, ибо каждый дурак начнёт клепать свою супер-пупер ненужную программу, которая тянет 100500 Гб библиотек с собой. На винде практически весь софт юзает API или что-то родное, вроде net framework-а (у нас же xlib не очень популярен), а теперь представь, что каждое маломальское окошко будет тянуть с собой огромный Qt, GTK или ещё какую-то фигню.

Кубунта 15.04, а плазма из ppa:kubuntu-ppa/backports

При наборе apt-get install package он показывает то что должно быть установлено, а это приводит к обновлению.

И при чём тут удаление программ?

Перешёл я тут, значит, на 5 плазму и что? Я вынужден терпеть то, что пакетник ставит мне дрова на amdgpu которых у меня никогда не было и врядли когда будут. И nouveau за каким-то. Попытка удалить это ненужно заканчивается конфликтом зависимостей: это ломает то, а это вот это.

Ох, лол, это где такой адок?

Тут нужен полный reset культуры упаковывания пакетов.

В арче всё норм. А если кажется, что какой-то пакет собран с чем-то лишним для вас, то всегда можно подправить пкгбилд.

Надо использовать LTS.

По этому переносимые файлы с приложенными библиотеками не нужны. Они не должны тянуть с собой ничего кроме себя. При распаковке пакета менеджер просто доустановит зависимости и создаст ссылки между /opt/pkg/libs/libcute/libcute.so в /opt/pkg/super/puper/libcute.so
Ну а ещё в корень, например.

Интересно.. А в чём роль pkgscript?

Ну это что-то вроде ebuild'a или PKGBUILD'a . Только он универсальный для всех пакетов репозитория. Все кастомизации либо в дополнительной инструкции, либо в полностью новом pkgscript.custom

А смысл?

gobo linux

Пакетная система это говноедство и пережиток прошлого, когда был медленный и ограниченный интернет.
Это очевидно абсолютно всем, в том числе убунтушникам с их snappy.

[list=1]
[*]Cтатическая линковка:
[list=1]
[*]Система превращается в винду, сложность замены библиотек на более новые с исправленными уязвимостями. Но для обновления можно попытаться перелинковать их не перекомпилируя.
[*]Дублирование библиотек в рамках дистрибутива. Но в ядре есть функциональность дублирования одинаковых участков оперативной памяти. 
[*]Не все программы можно так собрать. Glibc не готова для статики, но есть musl.
[/list]
[*] Установка каждого пакета в собственную папку и управление библиотеками через симлинки:
[list=1]
[*] Сложноватая система. Нужен принципиально новый пакетный менеджер.
[*] Нужно менять путь к библиотекам при компиляции. Есть случаи когда это невозможно?
[*] Многоуровневое файловое дерево.
[/list] 
[*] Установка конфликтующих пакетов в отдельное пространство имён для процесса:
[list=1]
[*]Эта технология используется кажется для виртуализации, но можно упростить её для такой цели. Это не докер, а просто ядро будет подставлять например разный /usr/ для разных процессов. Немного похоже на Plan9.
[*]Стандартная компиляция. Довольно просто прикрутить к стандартным дистрибутивам.
[*]Путаница с пространствами имен. 
[*]Не охватывает ядро и драйвера.
[/list]
[/list]

1. Cтатическая линковка:
   1. Система превращается в винду, сложность замены библиотек на более новые с исправленными уязвимостями. Но для обновления можно попытаться перелинковать их не перекомпилируя.
   2. Дублирование библиотек в рамках дистрибутива. Но в ядре есть функциональность дублирования одинаковых участков оперативной памяти.
   3. Не все программы можно так собрать. Glibc не готова для статики, но есть musl.
2. Установка каждого пакета в собственную папку и управление библиотеками через симлинки:
   1. Сложноватая система. Нужен принципиально новый пакетный менеджер.
   2. Нужно менять путь к библиотекам при компиляции. Есть случаи когда это невозможно?
   3. Многоуровневое файловое дерево.
3. Установка конфликтующих пакетов в отдельное пространство имён для процесса:
   1. Эта технология используется кажется для виртуализации, но можно упростить её для такой цели. Это не докер, а просто ядро будет подставлять например разный /usr/ для разных процессов. Немного похоже на Plan9.
   2. Стандартная компиляция. Довольно просто прикрутить к стандартным дистрибутивам.
   3. Путаница с пространствами имен.
   4. Не охватывает ядро и драйвера.

Пожалуйста!

Ну а я так не умею - вот скачал исходники Doom3-bfg посмотрел что нужно ему установил пакетником и сконпелял. Как по другому то?

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

Блин, а ведь эти вопросы перетирают еще со времен года так 97го или 95го, когда жизнь в эхе RU.LINUX бурно кипела и про интернеты только слышали, из книжек Эви Немет.

Ладно, для школоты придется повторить:
Тогда был доступен на раскладках РедХат, в основном его брали и про него знали. Многоболвановчный Дебиан казался монстром.

Дистры Шапки 5..6 занимали всего 650МБ.
И вполне логичным казалось применение пакетных менеджеров и не было зоопарка ДЕ, которые вообще на Вавилоне тулкитов сейчас шевелятся.
Тогда еще все с Винды95й рыготали, как она разваливалась.

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

здорово из всего этого я пользовался только apt-cache и apt-get. удивительно, но этого мне всегда хватало на все 100%.

т.е., вы не признаёте, как платформы, макосх, винду и адроид с айос? а что же тогда у вас «всё без неё работает»?

идеальная

Нет такой и не будет. А для реального мира изобрели Docker. То ещё поделие, но лучше, к сожалению, ничего не придумали.

это где такой адок?

Идеальная пакетная система. (комментарий)

а плазма из ppa

Это многое объясняет.

Ага. Ставил на свой страх и риск, и огрёб.
Хотя сидел когда на lts, сильно лучше не было, даже без ppa.
В систему тоже лез всякий хлам, а попытаешься его дропнуть, и начинается свистопляска.

никогда

И почему я тебе не верю

Школоте припекает от того, что критикуют его прелесть?

И почему я тебе не верю

Не знаю. Почему?

Скрипт будет видеть из какой директории запущен и на основе этого принимать решение о том какой пакет ставить?
Ещё запускать дополнительные инструкции из пакета?
Звучит как красивая идея, но я всё ещё не до конца понял..
Почему легче опакечивать make install?
Круто, да.

Смысл в том чтобы управлять версиями библиотек для каждого пакета в отдельности. Даже если все они будут использовать одну версию (должны к этому стремиться), то всегда можно это изменить.
Это позволит ставить много программ одновременно, это позволит ставить программы из более старой или более новой версии дистрибутива. Встроенная, общесистемная реализация смены альтернатив для каждого пакета.
А ещё организация по программам кажется более удобной чем организация по типу.