Пакетный менеджер под винду

Говорят, в восьмёрочке будет.

http://habrahabr.ru/blogs/windows/117357/

> Вот интересно, а что M$'у мешает запилить пакетный менеджер для винды?
В Windows 8 они собираются сделать application market.

Кстати, в ReactOS некое подобие репозитория уже существует.

Будет в Windows 8. Что мешало? Их интересует прибыль, пока apple не показала мелкомягким, как на appStore можно зарабатывать - им и не надо было. Таже история и с андройдом, кстати.

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

>само качало .net, directx и прочие необходимые фигни, которые как правило, програмки несут с собой
Никакие нормальные программки не несут с собой DirectX и .NET. Исключение составляют те, которые на CD или DVD, но это удобнее: зачем качать DirectX или .NET из интернета, если он точно такой же лежит на CD. Что касается всех остальных библиотек, то в винде с ее огромным количеством софта такая централизация, наверное, никогда не произойдет.

не разводило срач (как в папках, так и в реестре)

Неужто есть такой менеджер пакетов, который не позволит программам разводить срач у меня в ~ и ~/.config?

и следило за обновлениями.

Вот это единственное, чего недостает.

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

Первое время - это лет 10, как минимум. А потом уже и вендекапец наступит.

А потом производители ПО бы увидели как это круто и стали бы делать пакеты.

И распространять их сами? Тогда какое бы было отличие от MSI? Отдавать их MS? Очень им это нужно.

>В Windows 8 они собираются сделать application market.
Тут есть некоторое отличие от того, что предлагает автор.

Были уже проекты пакетного менеджера под винду.

А вообще чем вам msi не пакеты? В последних виндах даже дельта-пакеты появились, msp.

Есть как минимум костыли типа http://code.google.com/p/windows-package-manager/ . И да, в 8-ке будет.

>А вообще чем вам msi не пакеты?

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

>8-ке будет
не будет, это был фейк

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

Это скорее недостаток «нормальных пакетных менеджеров». Что если пакет Y является расширением/дополнением для пакета X и ему нужно перезаписать файлы? Особенно если оба пакета поставляются каждый на своем CD? Разве что заставить юзера разрешить ovewrite, что иногда не так просто сделать (в смысле, разрешить overwrite, а не заставить юзера).

Вообще юниксовые пакетные менеджеры очень, очень негибкие.

>Это скорее недостаток «нормальных пакетных менеджеров».

Это не глюк, это фича. В противном случае получаем Слаку.

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

>Вот интересно, а что M$'у мешает запилить пакетный менеджер для винды?

И без ms всякие win-get'ы существуют. А в SFU можно целую генту поставить

>Это не глюк, это фича. В противном случае получаем Слаку.

Слаку мы получаем только если существующую систему рушим, а новой не строим.

ZeuApp

Вообще юниксовые пакетные менеджеры очень, очень негибкие.

Ты с portage знаком?

там разве что только будет какой-то софтовый магазин (Store), не?

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

ну вот допустим я из msi ставлю неро, а оно мне докачивает си рантайм с апдейтами
не оно?

>Ты с portage знаком?

Шапочно. Но он ведь собирает из исходников, а для prebuilt-пакетов его возможности сильно ограничены. Потом, ведь Paludis не на пустом месте появился?

Хотя я думаю, мне действительно следует пересесть на постоянной основе на Gentoo на несколько месяцев и узнать о свежих веяниях в Ъ-линуксе.

Для prebuilt-пакетов нормальный менеджер пакетов вообще не возможен ИМХО.

http://rpm5.org/

Дело не только в том, что микрософт не знал, как зарабатывать - разработчики сами это еще могли не понимать. И дело даже не только в Apple. Valve, например, при помощи Stream, привлекла кучу инди-разработчиков. Кроме того, цифровая дистрибуция дала вторую жизнь старым играм.

>Вот интересно, а что M$'у мешает запилить пакетный менеджер для винды?

Архитектуру венды между низкоуровневыми компонентами и пользовательскими придётся для этого менять очень сильно. И обратная совместимость при этом сильно пострадает, так как много кривых, но популярных приложений сделано. Да и реестр свою роль тут тоже играет.
В общем - defective by design

proud_anon> Неужто есть такой менеджер пакетов, который не позволит программам разводить срач у меня в ~ и ~/.config?

Этот «срач» не нарушает работоспособность системы, в отличие от реестра. Просто потому, что то обычные конфигурационные файлы, которые никому не мешают.

proud_anon> Это скорее недостаток «нормальных пакетных менеджеров». Что если пакет Y является расширением/дополнением для пакета X и ему нужно перезаписать файлы? Особенно если оба пакета поставляются каждый на своем CD? Разве что заставить юзера разрешить ovewrite, что иногда не так просто сделать (в смысле, разрешить overwrite, а не заставить юзера).

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

proud_anon> Вообще юниксовые пакетные менеджеры очень, очень негибкие.

У тебя какой дистрибутив, неосилятор ты наш?

wxw> ну вот допустим я из msi ставлю неро, а оно мне докачивает си рантайм с апдейтами

Автоматизация DLL-Hell?

и следило за обновлениями.

Вот это единственное, чего недостает.

емнип, в винде есть API для Windows Update (которое может обновлять что угодно, а не только windows), и кое-кто им даже пользуется. Так что централизованное обновление существует.

Тогда какое бы было отличие от MSI?

яротно лорчую

Автоматизация DLL-Hell?

dll-hell у ниасиляторов COM ;) Берем любой интерфейс, проверяем версию, если надо — спрашиваем, есть ли в системе более новая версия — вот так правильно. Кстати, много ли линуксовых библиотек так умеют?

>следило за обновлениями

Учитывая тенденцию производителей ПО продавать новую версию продукта заново - не нужно. Саму себя и смежные пакеты MS семерка обновляет и замечательно. Остальное просто не выгорит - неужели думаете, Adobe в своих репозиторях будет 10 лет держать старый Photoshop для тех, кто купил, но до новой версии не обновлялся.

Почти все. Только вместо того, чтобы спрашивать версию, просто проверяют имя файла.

>ведь в *nix системах с пакетным менеджером ничто не мешает поставить софт не из пакета

А скажем CS5/AutoCad/Компас? Студенческие наколенные поделки/перлы-однострочники не показывают ровным счётом ничего

>Этот «срач» не нарушает работоспособность системы, в отличие от реестра. Просто потому, что то обычные конфигурационные файлы, которые никому не мешают.

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

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

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

Да ну?

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

>Что если пакет Y является расширением/дополнением для пакета X и ему нужно перезаписать файлы?

Что потом будет с пакетом X если пакет Y будет удалён?

>Что потом будет с пакетом X если пакет Y будет удалён?

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

Тогда это будет идеальная ОС.

>У него могут быть средства для восстановления собственных файлов или резервная копия старой версии, которую postrm-скрипт пакета Y будет восстанавливать

В итоге получится такая же каша, как сегодня в Windows. Нафиг нужно.