Библиотека для управления версиями программ изнутри - никто не пробовал такое сделать?

зачем это надо?

чтобы люди осознали всю полезность утверждения «есть две версии - текущая и устаревшая» :)

а мне она нужна для того, чтобы спокойно ставить зависимости от нужного номера версии, или от нужного номера коммита в SVN и не задумываться над всем этим гадюшником с пакетами. Что и сколько оно там нагенерит автоматом - поровну, на тестовых серваках (где быстрый подбор зависимостей важен) жестких дисков более чем дофига, а на боевых серверах с зависимостями будет трахаться специально предназначенный для этого человек.

чтобы люди осознали всю полезность утверждения «есть две версии - текущая и устаревшая» :)

оно может и полезное, но далекое от реальности.

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

это далеко от десктопного применения.

люди, я завидую вашей наивности.

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

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

резюмируя. соберите хоть раз LFS (желательно не из версий указанных в буке, а из самых последних), и сразу станет понятно, что такое работа мантейнера. а следом подобные идеи перестанут возникать сами собой.

резюмируя. соберите хоть раз LFS (желательно не из версий указанных в буке, а из самых последних), и сразу станет понятно, что такое работа мантейнера. а следом подобные идеи перестанут возникать сами собой.

если разработчики сами будут собирать свой софт — надобность в мейнтейнерах пропадет.

сейчас пытаюсь собрать pixelLight под gentoo)

В общем, ясно, что от пакетного менеджера не уйти(

Или nixOS попробовать

если разработчики сами будут собирать свой софт

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

статическая сборка не вариант

это почему еще? пользуюсь постоянно статическими сборками google chrome, deadbeef, eclipse, firefox, skype, flash — вполне вариант. правда, некоторые из них собраны криво (skype динамически зависит от libtiff, а chrome от linpng12), но все это решаемо. лучше так, чем никак.

и да, класть все необходимые либы в папку с программой — для меня тоже вариант. хотя и не лучший, т.к. придется запускать с LD_LIBRARY_PATH=/opt/appname/lib, а это не очень удобно.

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

кроме того, есть еще одно - конфигурация сборки. многие программы программы поддерживают различные варианты сборки, с разными зависимостями, разным функционалом и даже разным поведением. в случае дистрибутивов, решение как собирать принимают мантейнеры (с учетом политики дистрибутива и прочих вещей). а как должен собирать разработчик? все возможные варианты?

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

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

Чем тебя не устраивает наличие выбора?

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

зачем в системе несколько десятков libpng?

отвечу вопросом на вопрос. сколько у тебя установлено прикладных программ на компе (которые не являются частью базовой системы или частью DE), в которых используется libpng? что-то не верится, что несколько десятков. в любом случае, мне не жалко несколько сотен килобайт места на hdd.

в случае дистрибутивов, решение как собирать принимают мантейнеры (с учетом политики дистрибутива и прочих вещей). а как должен собирать разработчик? все возможные варианты?

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

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

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

Эмм...в плане фантастического бреда под грибами, продолжу тред :) Торрент-пакетный-частично source based менеджер. Идея: 1. Собирают пользователи из исходников то, что надо им и как им надо. Получится куча вариантов одного и того же. Причем «майнтайнеры» будут законодателями мод и соберут свои дистры сразу и как надо, сотальное на вкус и цвет. 2 Версии описываются «фичами и версиями фич». Это и параметры сборки и прочее. Описание генерится автоматом по введенному стандарту типа xml shema. Который автор пакета могет и сам расширить для добавления своих фич, которые есть только у него в проге и только у них есть версии. 3. Пакетник пользователя подрубается к серверу и там выдает запрос «мне надо то то и тото» и берет либо собранное дистром-майнтейнером, либо если надо что то особенное у других юзверей, либо берет исходники и собирает сам. Полностью автоматом прямо с сайта автора (который поддерживает фичу с торрент-менеджером).

Получаем: 1. В виде торрента, огромную распределенную сеть сборки пакетов с ох...большими выч. ресурсами. 2. Разнообразие пакетов начиная от «дистровых» и заканчивая «собери сам» 3. Отдельному пользователю не надо парить мозг если не хочет, поствил «обновись» в дистр и оно нашло для всего, что у него стоит следующие версии, а что не стоит подняло виагрой :)

В общем как то так. Реализацию можно крутить, но суть в торрент-менеджере и «описании фич»...как сейчас и есть в configure всяком.

и где здесь ответ на мой вопрос?

Мммм...нуууу...эээ :) Получится, что все дистры обитают в единой среде - метадистра. Выбор есть, но среда одна...все счастливы.

Мммм...нуууу...эээ :) Получится, что все дистры обитают в единой среде - метадистра. Выбор есть, но среда одна...все счастливы.

А теперь придумай как обеспечить безопасность такой среды :D

Подписи к пакетам...как и сейчас сделано кое где везде :)

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

А «поддержка автора» сводится к тому, что он в своем xml shema и xml описании софтины указывает какие другие схемы-описания должны быть у софтин с ним связанным. Пакетманагерюзверь качает это все и запрашивает в том же торренте наличие. После чего скачивает целевую софтину автора и собирает (или нашел в бинарнике сразу все). Если чего то не хватило, собирает сам автоматом или передавая это дело в опубликованные «собиратели». В общем счастье в фантастическом городе :)

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

собирается наиболее востребованный вариант

ты не учел один момент - дистрибутивов больше (намного больше) одного. а разработчик - один (или одна команда разработчиков)

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

на самом деле, даже если представить, что все разработчики вдруг начали собирать свои программы, думаю ничего бы не изменилось. пока доступны исходники, одни люди так и продолжали бы собирать дистрибутивы (а заодно убирать самообновление), а другие - использовать их. я думаю, что существующий подход часть чего-то большего чем ОС линукс. это часть философии, которая позволила этой системе родиться и благодаря которой она продолжает существовать. и эта часть неотъемлима.

если бы был «единый дистр», допустим, на базе srpm(чтобы и аналог use-флагов, кому нужно, а по умолчанию - из бинарников) с возможностью установки различных систем инициализации(в основном различие между дистрибутивами сводится к этому), то выбор ничуть бы не пострадал, а вот бессмысленной траты ресурсов на адаптацию одних и тех же программ к примерно одинаковым средам(одних только rpm-based дистрибутивов сколько) станет меньше. Только это утопия, потому что завтра кто-нибудь изобретет очередной революционный формат пакета и вокруг него начнут городить новый дистрибутив. Это печально

Идея правильная, но при реализации будут нюансы.

Мне кажется, что ближе всего к этой идее - Gentoo:

Торрент-пакетный-частично source based менеджер

Gentoo source-based. Есть и бинарники когда это надо. Но не вижу ничего плохого в том, что пакет нужно собирать после скачивания. Да, не торрент, но скачивание быстрое.

Версии описываются «фичами и версиями фич». Это и параметры сборки и прочее.

USE-флаги в Gentoo.

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

Дистростроители Gentoo берут не голые исходники, а накатывают на них свои какие-то патчи. В большинстве случаев эти патчи просто обеспечивают совместимость, устраняют баги (если мейнтейнер паета еще не включил в основную ветку). Но иногда этих патчей хватает на отдельный пакет. Например, в репозитории более 10 версий ядра: базовая (gentoo-sources), hardened-sources, git-sources, tuxonice-sources, pf-sources и др.

Пакетник пользователя подрубается к серверу и там выдает запрос «мне надо то то и тото»

USE-флаги, кроме включения-выключения фич определяют зависимости, которые тянет пакетник.

Это ... ты только Поттерингу не говори про свою идею, OK ?

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

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

ты не учел один момент - дистрибутивов больше (намного больше) одного. а разработчик - один (или одна команда разработчиков)

что это меняет?

это часть философии, которая позволила этой системе родиться и благодаря которой она продолжает существовать. и эта часть неотъемлима.

а по-моему это легаси, которое эту систему только тормозит в развитии.