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

Чем это лучше пакетных менеджеров?

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

Так на винде. Так обычно выкладывают на git или что-то аналогичное. А проекты которые пилятся в одного и обновляются только на сайте автора - редко представляют что-то адекватное.
Или ты хочешь, что-то что-бы собирало с гитхаба, «ланчпада» sourceforge и.т.д?
Опять же сделать это нетрудно, просто понимаешься не всегда выкладывают в одних и тех же каталогах и.т.д. Разные ветки. Короче это все равно желательно связываться отдельно с каждым проектом, чем вряд ли кто займется. А за самыми последними версиями редко, кто гонится. А если нужна последняя версия чего-то что прям руки горят, то можно и ручками стянуть.
Короче это просто не нужно.

http://otvet.mail.ru/question/11069947/
http://www.flowersweb.info/forum/forum6/topic72127/messages/

Во-первых не юниксвейно. Во-вторых никто свой софт под этот велосипед переписывать не станет. В-третьих, как гарантировать, что вместо зоопарка пакетных менеджеров не появится зоопарк этих твоих демонов?

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

cp ololo lolol

Cp нашел новую версию 3.2.4.6. Отложить копирование и выполнить обновление [y,n]?

Т.е. работу мэнтейнера (по тестированию дистрибутива на внутреннюю непротиворечивость и совместимость) перенести на сторону пользователя. Или, вообще, поручить эту работу демону с random-стратегией сборки — авось пронесёт, авось соберётся, авось заработает, ну, а если не заработает, то осталось всего 100500 вариантов сборок, как раз к концу третьего тысячелетия все и пересоберём.

Программа должна заниматься своим делом

и это говорит любитель емакса.
Вот он то как раз может обновляться изунтре. :)

На винфак.

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

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

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

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

Кактус у них и гниет и цветет? Хм.

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

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

Да, есть такая штука: Sparkle.

А либы как обновлять? А если я хочу всю систему разом обновить, мне все программы по очереди пускать? А если новая версия A требует новой версии B. Мне вручную всё это разруливать и запускать сначала B, ждать, пока оно обновится и запускать A?

Ну вот если проследить тенденции системд, етц... То, наверное, packagekit можно будет через дбас запрашивать обновление. Хотя не знаю пойдут ли они так далеко.

чтобы решить проблему, которую ты описал, как раз придумали пакетные менеджеры и rolling release

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

для этого должны быть права рута, так? Если у тебя есть права рута любым способом, ты можешь в фоне вызвать шелл и дать команду на обновление пакетному менеджеру. Если нужна навигация по версиям в комбинации с вытягиванием из git'а или другого репа, то в арче можно задавать версию переменной окружения, которую дальше использовать в аурбилде (все в том же уже запущенном шелле, из которого ты будешь давать команду на обновление). Т.е. необходимая «библиотека для обновления» уже есть - она называется шелл + пакетный менеджер + соответствующие права. /thred

тебе пришли в голову плохие негодные мысли. Гони их

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

которая позволяла бы приложению унифицированным способом обновляться изнутри

это та гадость, которая в firefox постоянно пишет: вышла очередная бета версия! обновитесь до нее. При том, что я использую стабильную.

В общем, это ненужно. Нечего программам чего-то качать извне.

Хотя не знаю пойдут ли они так далеко.

они - кто? Что сейчас мешает через dbus запрашивать обновления у packagekit Вешаем демон, пусть висит и ждет запроса, на запрос пускаем шелл и дергаем из него packagekit, профит.

вышла очередная бета версия! обновитесь до нее.

помойму команда Firefox с тобой не согласна. Есть всего две версии Firefox: стабильная и устаревшая. /кэп

на уровне организации файловой системы почти у всех всё одинаково или в крайнем случае приведено к пристойному виду симлинками

Взять хотя бы ту же неопределённость init.d / rc.d... Куда класть конфиги с инит-скриптами?

Роллинг-релизы порождают несогласованность. Вот берёшь такой и компилируешь свой hello world посредством clang'а, а компилятор берёт такой и валится на обычном shared_ptr. А потом оказывается, что у авторов C++ 2011 шило в одном месте заиграло и [неинтересные подробности стандарта]. И либо ставишь libstdc++ 4.7, либо допотопный clang. И это так, цветочки.

Чтобы решить проблему роллинга, которая всем очевидна, как раз придумали фиксированные сроки и единую дату, которую гном юзает с 2003 года, а убунта с 2004.

они - кто?

Ну, если они представят это как фичу, то нужно будет просто послать сигнал по дбасу и отловить ответ — всё остальное сделается само. Вместо:

на запрос пускаем шелл и дергаем из него packagekit

Хотя я точно не знаю, может так уже и есть.

Мне регулярно выскакивает сообщение обновить до 15 beta 4. Но я использую 14

Роллинг как раз рождает единообразие. Разработчики софта (и мантейнеры) читают рассылку и точно знают, что изменилось в системе. И что это что-то изменилось у всех примерно одновременно. А если у кого-то возникли проблемы совместимости, есть магическая кнопка «сделай мне зашибись», называющаяся «полное обновление системы». «pacman -Syuad» в данном случае. Не работает pidgin из-за неправильной версии $libname? pacman -Syu. Проблема с shared_ptr? pacman -Syu. У нас есть какие угодно проблемы, но не то, что ты написал ;)

У нас при разработке на жаве введен полный continuous integration (аналог RR для программистов :). Каждые N минут, каждый раз при запуске IDE, каждый раз при сборке проекта, система управления проектом проверяет изменения в зависимостях, в т.ч. заливает и линкует с самыми новыми версиями библиотек. Каждое новое изменение, покрытое автоматическими тестами, проходит автоматическое тестирование каждые N минут (на самом деле, так быстро, как позволяют ресурсы билд-сервера), в том числе всё постоянно тестируется на корректность работы с новыми версиями библиотек.

Проблема с RR (по крайней мере с RR в арче) - отсутствие покрытия автотестами, и, соответственно, необходимость постоянно проверять все ручками и срать в мэйлинг-листы. Как тут недавно товарищ залил нерабочий syslinux в тестинг, я завопил, а меня начали упрекать что типа «это же тестинг, для того и сделано, чтобы натыкались на баги».

чтобы все дистрибутивы одновременно ломались? ;)

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

да и дистры слегка разные, так что, кажется мне, пакетный менеджер - это оптимально! :)

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

И создаст зоопарк в стиле кладу свои файлы куда хочу и как хочу, а так же удаляю чужие.

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

И что, заказчик или там пользователи тоже берут версию из CI? ;)

Обычно вариации роллинга отделены от конечного продукта по двум причинам; во-первых, все люди, задетые CI, могут разобраться даже в нетривиальной проблеме и, возможно, сами её вызвали, распространять же карантин на весь город из-за ветряной оспы в детсаде №9 более чем странно; во-вторых, в любой разработке есть задачи долгие и не очень, что на роллинг ложится не очень хорошо.

У роллингов есть ещё одна проблема: некоторые из людей, что участвуют в их разработке, совершенно не понимает сути дистрибутивов. Дистрибутив - это вам не «пацаны, смотрите, я тут крутую прогу на районный сервачок закинул». Это не билд-серверы с собранными наспех исходниками. Это не сломанный syslinux на тысячах компьютеров. Ментейнерам показывают программу с 3 функциями и 10 страницами красноглазых мануалов к ней - а они смеются. Ментейнерам дают вейланд, которого всякие админчики панически боятся и ниасиливают, а они смеются и просят ещё, собирая его в своих factory и годами не пуская в релиз. Ментейнеры решают, какой подход заслуживает внимания и кого спонсировать, а кто только заставляет других делать бесполезную работу. Крупные дистрибутивы - практически единственные, кто может взяться за крупную, неприятную, годами всех мучающую задачу и всё-таки решить её, просто потому что иначе система получается несогласованной.

В итоге в разработке дистрибутивов с фиксированными сроками используется тот же самый роллинг, но умный: пакеты идут не по мере обновления на сайте авторов, а по мере готовности ментейнеров довести их до нужного состояния. Гном выпускается в марте и сентябре с 2003 года, убунта выбрала себе срок на 1,5 месяца позже - им этого достаточно, чтобы решить всплывшие проблемы и написать патчи, но недостаточно, чтобы софт успел устареть. И если большая часть софта будет ориентироваться на те же сроки - ментейнерам только легче станет, т.к. у них тоже помимо пересборки пакетов и их тестирования есть другие долговременные задачи.

Вон и в рассылке Qt недавно завязалось обсуждение о релизе раз в полгода, начиная с выхода 5.0, только вот с датой промахнулись: сейчас получается конец ноября, как у убунты, а должно быть как у гнома - т.к. Qt сам по себе весьма качественный и нужно лишь 1,5 месяца на смок-тест пересобранных qt-шных программ. Я туда кстати отписал, говорят, к версии 5.2 (т.е. к следующей ubuntu lts) возможно и выровняют сроки.

DLLHell

/thread

есть случаи, когда пакетные менеджеры и rolling release неподходят.

Примеры: базы сигнатур, встраиваемые в приложение скрипты. В совокупности могут занимать до 99% объёма всего приложения и кстати использоваться несколькими прикладами.

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

А вот единого (в виде библиотеки), надёжного, годного API для таких целей нет - каждый городит свой огород в меру испорченности :)

зы Это насколько я понял мысль ТС :)

согласен со всем, чо

да, заказчики берут версию из CI. Формально есть еще и stable (протестированная живыми тестерами), но ей никто не пользуется, потому что месяц задержки - криокамера.

хочу рассказать тебе одну историю (которую переводил когда-то для Спольского): http://olegchir.livejournal.com/3522.html (жж ибо local.joelonsoftware.com is down not just for you)

tl;dr:

"Что разделило Orcale и Ingres," — пишет Мур — "так это то, что их CEO Ларри Эллисон выдержал стопроцентный рост, в то время как в Ingres решили, что им хватит и 50%." Руководители Ingres понадеялись на лучшее. Как говорит Мур, они чувствовали, что компания "просто не сможет расти быстрее, чем на 50%, и продолжать адекватно обслуживать своих клиентов. Никто не сможет. Взгляните на Oracle. Они обещают всё и вся, а предоставляют чуть более чем ничего. И каждый это знает. Клиенты их ненавидят. Они бьются об непреступную стену."

Конечно, в Oracle решили все эти задачи и затмили своего конкурента. И это меня обеспокоило. Где же теперь Ingres?

Так и у нас. Лучше хоть какая-нибудь фича (или багфикс) — через час, чем особо качественная фича (или особо качественный багфикс) — через месяц.

Да и сам я постоянно юзаю часть библиотек прямо из nightly-stable. Особенно из тех, что мы сами фиксаем, коммитим прямо в транк, и прямо оттуда же подключаем как зависимость =)

(Disclamer: кстати, это все было не про тот-самый-государственный-проект.)

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

Вы хотя бы ОП читали?

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

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

чтобы решить проблему, которую ты описал, как раз придумали пакетные менеджеры и rolling release

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

проблему отката на предыдущую версию программы

почему-то мне не хочется троллить на эту тему (и так написал тут сегодня больше, чем говорю за месяц IRL)

а спросить, что делает waker в толксах )))

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

что делает waker в толксах )))

я читаю лор только через трекер, на разделы не обращаю внимания :)

aur/ppa/pkgbuild/srcrpm?

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

(рекурсивно применяя такое вообще ко всем зависимостям с помощью специального метапакетного менеджера, использующего стандартный пакетный менеджер как «package assembly», можно даже собрать несколько разных линуксов с разными префиксами под конкретный софт и тем решить проблему невозможности отката в RR :)

«программа бывает двух версий: обычная и устаревшая» :) (кажется, кто-то из Мазилы?)

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

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

в ffmpeg меняют API постоянно — старые версии прог его не умеют

Да всё уже придумано =)

    <groupId>com.myhomepage.myproject</groupId>
    <artifactId>com.myhomepage.myproject.gui</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <packaging>jar</packaging>

    <dependencies>
        <!--  Gson: Java to Json conversion -->
        <dependency>
            <groupId>com.google.code.gson</groupId>
            <artifactId>gson</artifactId>
            <version>2.2.2</version>
        </dependency>
    </dependencies>

Это Мавен, тащем-то, например.

Ты указываешь напрямую, что твоя либа зависит от gson версии 2.2.2. Если в системе «основная» версия скажем, 3.3.3, то это не повод печалиться. Просто пакетник скачает и соберет предыдущую версию (2.2.2) с другим префиксом. Если зависимости старой версии потребуют еще каких-то старых версий - он скачает и установит их с другим префиксом тоже.

Я начинал писать такую штуку в январе этого года на основе Мавена, но задолбался (из-за убогости и самого Мавена, и самого Линукса в его негибкости с lib search path =) и бросил. Может, стоит реанимировать идею. Технически всё еще возможно, хоть и с извращениями (configure && make && make install разнесет такую систему в клочья).

это из серии «если бы существовал такой пакетник».

Просто пакетник скачает и соберет предыдущую версию (2.2.2) с другим префиксом.

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

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

они и будут постоянно дублироваться. Анонимные аналитики прогнозируют рост объема до пары сотен гигабайт =)

ну и соответственно, возникает вопрос — зачем это надо?