Планы по кросс-форматному пакетному API в LSB

>А что будет если в зависимостях версия glibc в "левом RPM" не совпадёт с вашей текущей установленой ;) ?

Он скажет что фиг там было. Что первый раз что-ли? Когда апдейт вылезает зеркало бывает не всегда успевает все вытащить и когда я говорю мол "валяй" он говорит - "хрена с два". Жду пару часиков и потом устанавливаю. Так что если левый rpm с glibc который не мое - менеджер будет сопротивлятся. А какие варианты?

>Речь о том, что не будет RPM'ов, вместо RPM'а --- инсталлер (как привыкли в Винде)

Нефига - перечитай текст. Речь о том что нет стандартного API позволяющего любым установщикам интегрироваться в систему нормально. Если я ставлю что-то с помощью InstallAnywhere - они не имеют возможностей интегрировться в существующий PM дистрибутива. Цель как раз обратная - дать им возможность ставиться нормально, чтобы после installanywhere я заходил в yast и все там видел и рулил.

Ничего плохого не вижу в том что апи интеграции в конкретный PM любого дистра будет стандартизирован.

Решение с репазитариеми безусловно лучше, но стандарта на репозитарии нигде нет. И проблема та же самая - не будет скажем тот же IntelliJ фигачить тучу репозитариев для сотен дистрибутивов.

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

>дать им возможность ставиться нормально, чтобы после installanywhere я заходил в yast и все там видел и рулил.

К стати при появлении стандарта - даже ./configure перестанет быть страшным - он тоже воткнется в PM дистра без вопросов, и все будет прозрачно. Нет пакета скомпилял сам - и тут же все синхронно и может быть снесено MPом или проапдейчено с ./configure прямо в дистровый пакет. Да это мегафича.

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

Э... а чем тогда зузя будет отличаться от дебиана?

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

+4, нехрен разброд и шатания из года в год поддерживать и усиливать. Одних RPM'ов развелось что можно полафрики к работе пристроить.

>Э... а чем тогда зузя будет отличаться от дебиана?

Стандартизирован же будет формат, а не контент:)

Мм... у дебовского репозитария формат простой как ... как я не знаю что. Если не вдаваться в детали - по каким принципам софт бьётся на пакеты.

>Мм... у дебовского репозитария формат простой как ... как я не знаю что.

Он у всех несложный. Проблема в том что он нестандартный.

Главное не перемудрить, а так идея неплохая.

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

> Речь о том что нет стандартного API позволяющего любым установщикам интегрироваться в систему нормально.

В чем заключается нормальность интеграции? Сослаться из инсталлера одной софтины на другую я всё равно не смогу, т.е. опять та же х-ня, как и в Винде: "Данная программа требует Foo-X.Y. Скачать можно тут: http://foo.com/dl/foo-x.y.bin";. При том, что это барахло прописывается в систему не имея реальных пакетов, единообразие управления пакетами нарушается. Я больше не могу взять список репозитариев, список установленных пакетов и ответов на вопросы конфигуратора при установке и восстановить это на другой системе, т.к. нужно руками запускать инсталлеры.

А зависимости... При таком подходе, это не плюс, а минус. Почему в Винде без них живут? Потому что там система ставится вся целиком, без вариантов. Поэтому удовлетворять зависимости внутри системы не надо, а во вне ее (между third party software) --- нечем. API позволит удовлетворять внутрисистемные зависимости (которые в Винде отсутствуют как класс, вместе с их проблемами), но зависимости между сторонними разработками удовлетворять будет так же нечем. Т.е. Винда + доп. геморрой с внутрисистемными зависимостями.

> Цель как раз обратная - дать им возможность ставиться нормально, чтобы после installanywhere я заходил в yast и все там видел и рулил.

Я и говорю --- API для Control Panel->Add/Remove Programs. Не более того.

> Решение с репазитариеми безусловно лучше, но стандарта на репозитарии нигде нет.

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

> И проблема та же самая - не будет скажем тот же IntelliJ фигачить тучу репозитариев для сотен дистрибутивов.

Так вот не лучше ли создать систему, которая из единого источника с описанием генерит пакеты и репозитарии для всех этих сотен? Тогда даже проблема с различием в репозитариях не будет стоять так остро. Не лебезить и стелиться под дерьмовые InstallAnywhere&Co, а предложить более качественную архитектуру для подобного рода приложений.

> Нет пакета скомпилял сам - и тут же все синхронно и может быть снесено MPом или проапдейчено с ./configure прямо в дистровый пакет.

Ну-ка, ну-ка, расскажи поподробнее, как PM бинарного дистриба будет апдейтить автоматически пакет при помощи configure&&make&&make install, если даже репозитария нет.

о чем собственно спор? самый простой и удобный репозитарий у генту

> Во первых с чего ты взял что он скажет /usr/bin а не /usr/local/bin?

Потому что, предполагается "интеграция в PM". Всё, что ставится PM'ом, ставится по правилам FHS, т.е. в /usr. /usr/local --- помойка для админа, куда он сваливает всякое барахло, не управляемое PM'ом.

> А что скинуть на отдельный носитель доставляемый недистровые пакеты религия не позволяет?

Ключевое слово тут --- пакеты. Пакетов нет. Есть бинарные инсталлеры, использующие API. PM о них нихрена не знает и знать не может. Соответственно, поставить их автоматически он тоже не может. Т.е. всё-таки в рукопашную. Такие "add-on cd" у меня были в те времена, когда я под Виндой работал. Автоматики это не добавляет, разве что повторно по Инету искать не надо. Правда, обновление идет лесом, т.к. ручное.

> Так все и останется. Не понимаю с чего паника.

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

может вы еще и аргументируете как-то? имхо, у генту не репозитарий, а просто свалка файлов в одной директории

>В чем заключается нормальность интеграции?

В том что после: InstallAnywhere, ./configure, etc установленная софтина попадает под контроль пакетного менеджера.

>Сослаться из инсталлера одной софтины на другую я всё равно не смогу

Это и не требуется - там где есть такой инсталер обчыно "статическая" сборка.

>При том, что это барахло прописывается в систему не имея реальных пакетов

А что такое "реальный пакет"? Когда это барахло приползло в систему и развернулось - уже не важно из чего оно приползло.

>единообразие управления пакетами нарушается.

Его и нет. Проблема не в тех кто уже делает репозитарии - они и так будут их делать. А в тех кто их _не делает_. Сейчас они вообще без интеграции. Захочу я поставить в свою зюзю haskell и что? А то что ./configure. И все мимо менеджера. А так оно попадет в менеджер и не важно что собиралось с исходников. Это как раз добавит единообразия - с PMамим смогут взаимодействовать те кто сейчас не взаимодействует.

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

Мы говорим о тех кто сейчас ходит мимо PM. Тебе и так сейчас нужно запускать инсталеры. Прочитай о чем новость то сначала внимательно.

>Почему в Винде без них живут? Потому что там система ставится вся целиком, без вариантов.

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

>API позволит удовлетворять внутрисистемные зависимости (которые в Винде отсутствуют как класс, вместе с их проблемами)

Они не отсутсвуют. В винде все статика или "хади сюда". И проблем нет - это миф. Попробуй снести что нить что ставиться в Common Files. Что оно говорит? "файлз мей би юзд но выянить этаго нимагу потому ты ССЗБ".

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

Бред несешь полный. Все перечисленные фичи и сейчас есть - просто они _нестандартизированы_. И после стандартизации они не исчезнут, а станут одинаковыми во всех дистрах. После этого откроется возможность third party нормально интегрироваться - это будет экономически оправдано.

>Я и говорю --- API для Control Panel->Add/Remove Programs. Не более того.

Сейчас нет даже этого. Любой установленный так софт идет вообще мимо кассы и нигде не учтен и ничем не менеджится.

>Так вот не лучше ли создать систему, которая из единого источника с описанием генерит пакеты и репозитарии для всех этих сотен?

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

Ответ - нет не лучше. Лучше выработать стандарт, который будет поддерживать каждый дистроклепатель.

>Не лебезить и стелиться под дерьмовые InstallAnywhere&Co, а предложить более качественную архитектуру для подобного рода приложений.

Да? Знаешь какая фича у InstallAnywhere _основная_? Ответ - кроссплатформенность. Сам InstallAnywhere и есть тем самым идиотом который под надцать систем написал "единый источник с описанием" и конвертирует его в инсталлеры под каждую операционку. Суть продукта именно в этом. Дык вот - чтобы заставить Install Anywhere работать с понятием "репозитарий" - ты сначала венды, аикса и прочие бизди с гентами заставь перейти на эти репозитарии. Вот тогда архитектура репозитариев будет в кассу а install anywhere будет ненужен. А пока производители кросплатформенного софта выбирают именно их потому что у них не только проблема разных линуксов, но и то всакие macosы с вендами.

>Ну-ка, ну-ка, расскажи поподробнее, как PM бинарного дистриба будет апдейтить автоматически пакет при помощи configure&&make&&make install, если даже репозитария нет.

Он не будет апдейтить. Я говорю о том что все что я скомпилал сам может быть снесено из системы PMом или заальтерено из репозитария или из левой rpm или из InstallAnywhere. Это и есть та самая ecosystem. Будет абсолютно пофигу откуда пришел софт - если он появился на моей тачке - он под управлением PM.

Я всё понимаю так. Есть формат пакетов. Есть софтина которая устанавливает эти пакеты. Когда ты устанавливаешь пакет к примеру в gentoo то будет генрится ebuild для установки данного пакета и на него затравливаться emerge, аналогично с rpm,deb и т.д. такую софтину будут разрабатывать всех колхозом. :)

> Потому что, предполагается "интеграция в PM". Всё, что ставится PM'ом, ставится по правилам FHS, т.е. в /usr. /usr/local --- помойка для админа, куда он сваливает всякое барахло, не управляемое PM'ом.

В этой твоей фразе 3 предположения высосанные из пальца.

1.Потому что, предполагается "интеграция в PM".

Из этого не проистекает что разработанное API не будет учитывать FHS.

>Всё, что ставится PM'ом, ставится по правилам FHS, т.е. в /usr.

Из этого не проистекает что PM прав в этом и вообще что можно однозначно определить что ставить в /usr/, а что в /usr/local. Пример: я ставил последний ocaml с помощью ./configure. Он естественно попал в /usr/local. Я могу вытянуть ocaml из suse репозитария - он станет в /usr. Еще пример: я вчерась поставил последний flashplayer из rpm которую утянул с adobe. Поставил через Zen - он стал в /usr. Если бы я утянул tar.gz стало бы в /usr/local? А теперь расскажи мне какая разница?

И заметь противоречие в собстенной фразе:

>/usr/local --- помойка для админа, куда он сваливает всякое барахло, не управляемое PM'ом.

Дык вот если после запуска InstallAnywhere это попадет под контроль PM - значит правильно что станет в /usr?

>Соответственно, поставить их автоматически он тоже не может.

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

>а тут собираются решение 20-летней давности застандартизировать надолго вместо более прогрессивного.

Потому что прогрессивное невозможно. Ты мотивацию читал?

>>а тут собираются решение 20-летней давности застандартизировать надолго вместо более прогрессивного.

>Потому что прогрессивное невозможно. Ты мотивацию читал?

Там какая-то неубедительная мотивация. "They're already dealing with a multitude of packaging systems." - ну так еще один формат будет, это что, такая большая проблема? RPM стандартизован в LSB.

>emerge все равно никуда не денется. Как прикрутить поверх него API не представляю и не вижу необходимости, помоему все и так достаточно удобно.

emerge умеет работать с rpm и deb. Так что такие изменения и его коснуться.

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

gzip есть везде, идёт везде и на всём. Вот бы они бинарные diff-ы придумали - было бы здорово.

>RPM стандартизован в LSB.

Не работает в венде и osx и bsd :)

>Там какая-то неубедительная мотивация.

Не та. Вот эта:

Applications like Install Anywhere and BitRock Builder provide installers comparable to those found on Windows, but, as Murdock points out, "They don't integrate well with the package systems. The result is like a tarball, except easier to use." The installers produced by such applications can neither check dependencies nor register installed programs with the package management system. Nor do they provide application management across a heterogeneous network, because administrative tools tend to be specific to a specific package system.

Поставь себя на место производителя кросплатформенного софта. Ему надо фигачить пакет под OSX,Win,xBSD, туеву хучу линуксов и т.д. Это люди и деньги. InstallAnywhere ставит себя на их место и говорит что за 4 косых баксов мы вам тулзень подкинем. Вы нам скажете де софт лежит, а уж иконки, реесты, десктопы и менюшки мы сами засетапим. Производитель естественно соглашается. Разница в том что тот же InstallAnywhere запихивается в менеджер венды и анинстал можно оттудава сделать. А в линуксе хрен нам - универсального апи нету, а зоопарк дистров они поддерживать не хотят - дорого.

Проблема действительно существует - я скомпилял себе ocaml. А яст его естественно не видит. Почему бы не разработать стандарт по которому конфигур зафигачит скриптец который совершенно универсально всунется туда? И тогда я зайду в яст и он мне покажет у меня стоит ocaml 3.09.2 в то время как в репозитарии 3.08, хотя в репазитарии собранный новелом rpm, а у меня на тачке я скомпилял его сам. И чем плохо то что я смогу через этот же интерфейс снести то что скомпилял, и поставить из репозитария?

Значит так, определимся с термином "под контролем PM". Дело в том, что софт, поставленный инсталлерами с этим API, всё равно не под контролем PM. Он не апдейтится автоматически, нельзя автоматически восстановить "как было" и пр. Единственное, что всё это дает --- это кнопочку Uninstall, но ее можно присандалить и сейчас, без навороченных API, по-моему, даже уже есть в стандарте скрипт для установки menu entries --- главное определиться, как назвать каталог для Add/Remove Programs, куда ссылки на uninstall'ы складывать. Удовлетворение зависимостей? Это еще один мини-скриптик: require-package bla-bla-bla, который дергает PM дистрибутива. А вот зачем мне в package system недопакеты, нихрена кроме удаления не могущие --- непонятно.

VMWare, например, колбасится себе в /usr/local, и снести ее в случае чего vmware-uninstall.pl'ем можно без проблем, и в apt'овой базе она совсем лишняя.

> InstallAnywhere запихивается в менеджер венды и анинстал можно оттудава сделать. А в линуксе хрен нам - универсального апи нету, а зоопарк дистров они поддерживать не хотят - дорого.

Ну так это тулзень неправильная :) Она должна конвертить свой пакет в "родной" формат (вроде alien "на стероидах"), и никакого API не нужно. Инструменты для создания RPM - есть, создать "тривиальный" (без развесистых зависимостей) очень просто. А слои трансляторов API - это будут глюки и грабли, и ради чего? Чтобы InstallAnywhere сэкономили на разработке своей версии alien?

> Почему бы не разработать стандарт по которому конфигур зафигачит скриптец который совершенно универсально всунется туда?

Потому что это не так уж просто. Это _было бы_ просто, если бы пакет представлял из себя только имя и список файлов. Но ведь пакет - это еще и Requires:, Provides:, Obsoletes: и куча всего, это API-контракт, на который рассчитывает зависящий от него софт, да много всего... Конечно, у configure есть почти вся эта информация, но у rpm есть опция -ta ;), да и .spec-файл для autoconf-пакета тривиален.

>Значит так, определимся с термином "под контролем PM".

Давайте.

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

А давайте без "и пр", а в виде списка?

Я перечислю список необходимых фич для управления софтом:

1. Инсталяция из репозитария. 2. Сборка из исходников. 3. Установка в виде стороннего rpm|deb. 4. Установка из tarball. 5. Установка third party исталятором (к стати есть ситуации когда вообще невозможно пользоваться репозитареим - например когда приложение генерируется другой программой - у нас такие есть и в венде мы как минимум в uninstall попадаем, а в линухе нет) 6. Снос любого из 1-5. 7. Замена любого из 1-5 любым другим из 1-5. 8. Апдейт с любого из 1-5 на любой другой из 1-5.

Ище есть?

Теперь посмотрим что имеем в существующих репозиториях: 1+ 2- 3+/-(в некоторых) 4- 5- 6-(только 1,~3) 7- 8-(только 1,~3)

Теперь представим, что у нас появилось стандартное API которое может внести в базу PM инфу об установленном софте. 1=(не изменится) 2+ - очень быстро в autotools появится скрипт который будет что надо где надо регать 3= 4- (не знаю как решить без стандартизации содержимого тарбола что сделает его подобием пакета) 5+ 6+ (-4)(можно будет через единый интерфейс снести программу вне зависимости от того как она была установлена) 7+ (-4) можно будет заменить любую программу вне зависимости от доступности версии в репозитарии, а так же заменить установленную третьей стороной, отдельной rpm, или вообще скомпиленную руками версию на репозитарийную как только она появится. 8+ (-4) можно делать update который будет под полным контролем PM. Если я ставлю версию N из репозитария, я могу не напрягаясь компилять N+1 и PM будет об этом знать. Равно как и наоборот PM может обнаружить что в ропозитарии воявилась более последняя версия чем та которую я скомпилял/поставил другой тулзенью и т.д. и (что немаловажно _сказать мне что существует update - сейчас он вообще не видит что что-то там установлено - он думает что не стоит)

>Это еще один мини-скриптик

Под какой дистрибутив? Или каждый по своему? Велосипедную фабрику откроем?

> А вот зачем мне в package system недопакеты, нихрена кроме удаления не могущие --- непонятно.

Могут - я перечислил. Или скажешь это нафиг не нужно? У меня сейчас стоит ocaml,xine. Яст думает, что не стоит. Классно? На днях зарелизилась симанка 1.1. В репозитарии его нет. Проапдейтится я немогу. Классно? А это бы решилось на раз-два будь стандарт.

>VMWare, например, колбасится себе в /usr/local, и снести ее в случае чего vmware-uninstall.pl'ем можно без проблем

То есть очередным велосипедом, который каждый под себя делает? Извини, но даже в венде решение лучше в add/remove.

>Она должна конвертить свой пакет в "родной" формат

Родной для кого?

>Чтобы InstallAnywhere сэкономили на разработке своей версии alien?

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

>Это _было бы_ просто, если бы пакет представлял из себя только имя и список файлов. Но ведь пакет - это еще и Requires:, Provides:, Obsoletes: и куча всего, это API-контракт, на который рассчитывает зависящий от него софт, да много всего..

Вот потому что его особостандартного нет - autotools и не парится - что он будет с ним делать? autotools чекает и так requires, знает что он provides и obsoletes. Только запихнуть это ему некуда. А если появиться апи которое он дернет и все сразу об этом узнают - тут же все нарисуется.

Но дело же не только в autotools. Как там сказано есть еще third party.

К стати еще попадем в дерево зависимостей!!!

10. Тот же конфигуре раскажен PM что он provides и я смогу установить программу из репозитария даже если то что оно requires из репозитария не установлено, но есть в системе!

>>Она должна конвертить свой пакет в "родной" формат

>Родной для кого?

Для LSB

>>Чтобы InstallAnywhere сэкономили на разработке своей версии alien?

>Они не хотят даже разбираться во всем этом зоопарке

Зоопарка НЕТ. Есть стандарт LSB, определяющий формат пакета.

> autotools чекает и так requires, знает что он provides и obsoletes.

Requires: он "чекает" очень неформально, Provides: и Obsoletes: он вообще никак не обрабатывает. Не говоря уже о версиях ABI, {pre,post}-{un,}install скриптах и прочем, о чем я уже забыл. Нескромный вопрос - ты сборкой пакетов и поддержанием репозитория занимался?

> А если появиться апи которое он дернет и все сразу об этом узнают - тут же все нарисуется.

Для этого надо 1) спроектировать и реализовать API, 2) ввести его поддержку в autotools, 3) заставить разрабов этим добром пользоваться. 1 и 2 - само по себе нетривиально, 3 - практически невозможно (разрабы - они не пакаджеры). А главное - зачем это нужно? Довести до ума alien можно с куда меньшими затратами сил.

> А в линуксе хрен нам - универсального апи нету, а зоопарк дистров они поддерживать не хотят - дорого.

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

> И тогда я зайду в яст и он мне покажет у меня стоит ocaml 3.09.2 в то время как в репозитарии 3.08, хотя в репазитарии собранный новелом rpm, а у меня на тачке я скомпилял его сам.

А что, скачать src.rpm от дистростроителя, накатить upstream, скомпилять и поставить --- неподъемная задача? За то, получишь полноценный rpm, который можно поставить на неограниченное количество машин без компиляции.

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

>. Не говоря уже о версиях ABI, {pre,post}-{un,}install скриптах и прочем, о чем я уже забыл

Он научится.

>1) спроектировать и реализовать API,

Ну народ вон и собрался это сделать.

>2) ввести его поддержку в autotools,

Думаешь не введут когда такая мегафича нарисуется?

> 3) заставить разрабов этим добром пользоваться.

Думаешь не воспользуются?

>3 - практически невозможно (разрабы - они не пакаджеры)

Это не так. Многие разработчики делают rpm. Если им нашару дадут возможность интегрироваться с PM - они этой возможность воспользуются.

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

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

>А что, скачать src.rpm от дистростроителя, накатить upstream, скомпилять и поставить --- неподъемная задача?

А нету src.rpm у дистростроителя.

> 1. Инсталяция из репозитария. 2. Сборка из исходников. 3. Установка в виде стороннего rpm|deb. 4. Установка из tarball. 5. Установка third party исталятором (к стати есть ситуации когда вообще невозможно пользоваться репозитареим - например когда приложение генерируется другой программой - у нас такие есть и в венде мы как минимум в uninstall попадаем, а в линухе нет) 6. Снос любого из 1-5. 7. Замена любого из 1-5 любым другим из 1-5. 8. Апдейт с любого из 1-5 на любой другой из 1-5.

2. - это не к PM. Точнее, к сопроводительным инструментам. Практически к любому есть обвязка, позволяющая быстренько и dirty склепать пакетик на поставить.
4. - это я не понял, что такое вообще.
5. - нафиг не надо вообще.
6-8. С этим справляются существующие PM.

Итак, моя версия.

1. Установка ПО.
2. Автоматическое разрешение зависимостей, включая автоматический поиск в доступных источниках (CD/DVD, Internet).
3. Сохранение/восстановление состояния (установленные пакеты, возможность восстановить систему в прежнем виде).
4. Сохранение/восстановление установочной конфигурации (ответы на вопросы при установке).
5. Автоматическое отслеживание обновлений.
6. Обновление ПО.
7. Автоматическое обновление ПО.
8. Учет конфликтов, зависимостей, структурных изменений при обновлении.
9. Удаление ПО.

Соответственно, современное состояние дел таково:

a) софт из репозитариев: 1-9
b) софт в бинарных инсталляторах: 1,6,9
c) софт в исходниках: 1,6,9

Доп. факторы:
* a,b,c практически не пересекаются, т.е. не мешают друг другу, но и не помогают.
* управление b,c непонятно неспецам.

Предлагаемое решение:

a) софт из репозитариев: 1-9
b) софт в бинарных инсталляторах: 1,4,6,9
c) софт в исходниках: 1,4,6,9

Доп. факторы:
* a,b,c пересекаются в базе PM, что препятствует нормальному выполнению 3 в целом.
* управление b,c становится чуть более понятно неспецам, хотя в современном состоянии можно достигнуть того же уровня.
* b,c ставятся с нарушением FHS, т.к. либо /usr/local уже не вотчина админа, либо в /usr стоят неполноценно управляемые PM'ом пакеты.

Резюме:
Ради одного сомнительного пунктика жертвуется цельностью существующей системы.

> Могут - я перечислил.

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

> очередным велосипедом, который каждый под себя делает? Извини, но даже в венде решение лучше в add/remove.

Насколько я понимаю, тоже самое делает InstallAnywhere&Co. Предлагаемое решение ничем не лучше этого. Использование пакетной системы для add/remove даже хуже, чем стандартизация установки ярлыков в меню и выделение стандартного места, которое будет служить коллекцией uninstall'ов для add/remove.

> К стати еще попадем в дерево зависимостей!!!

Не попадаем. См. ниже.

> 10. Тот же конфигуре раскажен PM что он provides и я смогу установить программу из репозитария даже если то что оно requires из репозитария не установлено, но есть в системе!

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

Случай 2. Бинарный third party пакет. Да всем пох чего он там provides и куда он это пропишет, если загружать и ставить придется вручную.

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

Обновление. Допустим, образ обновился для новой версии VMWare. PM мне скажет, что обновить не может, т.к. версии не совпадают. И по-новой.

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

Резюме:

Все равно всё ставится вручную, т.к. автоматического удовлетворения зависимостей нет.

>2. - это не к PM. Точнее, к сопроводительным инструментам. Практически к любому есть обвязка, позволяющая быстренько и dirty склепать пакетик на поставить.

Почему? В библии написано? Сорцовые дистры с тобой не согласятся.

>5. - нафиг не надо вообще.

А люди должны любить друг друга. Это есть. Это реальность. Это надо. Или решим проблему методом закрывания глаз?

>6-8. С этим справляются существующие PM.

Только с тем что происходит из понятия пакет.

>* управление b,c непонятно неспецам.

И что - спецы пускай долбятся?

>Ради одного сомнительного пунктика жертвуется цельностью существующей системы.

Какого сомнительного? Как мне обновиться с самоскомпиленной версии на репозитарйную?

>Ради одного сомнительного пунктика жертвуется цельностью существующей системы.

Чем жертвуется? В виде списка что потеряется в студию.

>Использование пакетной системы для add/remove даже хуже

Хинт - это ее основная задача.

>Вот бы они бинарные diff-ы придумали - было бы здорово.

man xdelta

>Насколько я понимаю, тоже самое делает InstallAnywhere&Co.

Правильно. И смысл стандартизации - чтобы все делали это одинаково и под контролем PM. Я не понимаю: это всего лишь стандартизация того что они и так делают, и возможность интеграции с ними софта который сейчас ни с чем не интегрируется. Сплошные плюсы.

>Еще раз повторю, что пакеты из исходников --- для разработчиков, а не для конечных пользователей

Рассажи это сорцовым дистрам.

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

Как?:)

>Да всем пох чего он там provides и куда он это пропишет, если загружать и ставить придется вручную.

Перепутал с requires? ТАкие пакеты ничего не requires кроме того что есть в любом дистре обычно.

Ты так говоришь будто это изменение введет что-то. Оно призвано разрулить _уже существующую_ систему. И это первый шаг на пути к унификации PM. А ты так говоришь как будто после принятия стандарта в линуксе запестрят setup.bin.

>Все равно всё ставится вручную, т.к. автоматического удовлетворения зависимостей нет.

Чего это его нет? Ты вообще под линукс холть одну софтину видел которая ставится тулзами типа installanywhere? Им _ничего не требуется_. Иначе нету никакого смысла в этом IA.

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

А как они делали сам софт под дистрибутив? Не следя за тем, что каждый студент наваял? А оно вообще-то работает?

Кроме того, раз мы говорим об LSB, то предполагаем, что установка производится не в дистрибутив "каждого студента", а в LSB-compliant, а там много чего, что сильно сужает число вариантов. Фактически, нужно поддерживать некоторое количество PM'ов, кое невелико, и LSB.

ХМ, портадж из генту:

- собирает из исходников

- ставит из прекомпилированых пакетов

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

Далее - софт распространяемый в бинарниках ставится просто замечательно, например дрова nvidia, vmware, googleearth и т.п.

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

> Я не понимаю: это всего лишь стандартизация того что они и так делают, и возможность интеграции

Это минимальные улучшения (InstallAnywhere&Co это ведь уже делают) ценой поломанной автоматизации уже существующего. Не стоит оно того.

> Сорцовые дистры с тобой не согласятся.

А тогда какая проблема, я не пойму? Т.е. с этим пунктом уже справляются PM'ы, которым положено. Тем лучше добавим дополнительно этот пункт тем, кто с этим работает. Но _пользователям_ бинарных дистрибов это не надо.

> Это есть. Это реальность. Это надо.

Потому что нет правильного решения. При его наличии, это не надо.

> Только с тем что происходит из понятия пакет.

А с тем, что из этого понятия не происходит, всё равно мало что можно сделать.

> И что - спецы пускай долбятся?

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

> Как мне обновиться с самоскомпиленной версии на репозитарйную?

Поставь репозитарийную и грохни свою. Я этим занимался, это не сложно, уверяю.

> Чем жертвуется? В виде списка что потеряется в студию.

Автоматизацией. В предлагаемом решении не все пакеты поддерживают все возможности пакетной системы, значит некоторые возможности недоступны совсем (автоматическое сохранение/восстановление состояния), а некоторые возможности нельзя использовать (автоматическая установка third party софта по зависимостям, автоматическое его обновление). Т.е. бенефиту ~0, а потери есть.

> А вот зачем мне в package system недопакеты, нихрена кроме удаления не могущие --- непонятно.

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

Да и вообще, если что-то можно сделать скриптом, это ещё не значит, что это нужно делать скриптом.

>А как они делали сам софт под дистрибутив?

А никак не делали. И не делают. В основном делается помаксимуму статически слинкованный дистр.

>Фактически, нужно поддерживать некоторое количество PM'ов, кое невелико, и LSB.

Это все равно дорого.

>ценой поломанной автоматизации уже существующего.

Ты так и незвал что жэ там поломается и с чего бы. Что? И почему?

> Но _пользователям_ бинарных дистрибов это не надо.

Я пользователь бинарного дистрибутива. Мне это надо. У меня стоит софт который поставлен из исходиков и софт установленный InstallAnywhere. И меня дико раздражает, что его не видит yast.

>Автоматизацией

Конкретнее. Что перестанет автоматизироваться?

>В предлагаемом решении не все пакеты поддерживают все возможности пакетной системы

Сейчас эти пакеты не поддерживают _никаких_ возможностей пакетной системы. НАчнуть поддерживать часть. Где минусы?

>Потому что нет правильного решения. При его наличии, это не надо.

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

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

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

>Поставь репозитарийную и грохни свою. Я этим занимался, это не сложно, уверяю.

Не сложнее чем нажать кнопку update в PM? Или таки сложнее?

Сча набегут слаководы и вообще разкажут что с hands и молитвой Патрику вообще PM не нужен.

А как её использовать-то?