Вышла Monodevelop 2.1.1

>А Qt Creator?!

А он в убунтушном репозитории есть? Не пробовал, в общем. Под Gentoo он есть, но я для себя без IDE-шек всё делаю :)

>А он в убунтушном репозитории есть?

а зачем, он довольно прозрачно ставится через инсталлятор...

> А он в убунтушном репозитории есть?

Так вот же ж: http://qt.nokia.com/downloads/sdk-linux-x11-32bit-cpp

>а зачем, он довольно прозрачно ставится через инсталлятор...

Ну, извините, я виндовые привычки под виндой оставил :)

>>а зачем, он довольно прозрачно ставится через инсталлятор...

>Ну, извините, я виндовые привычки под виндой оставил :)

Ubuntu вы тоже вручную собираете или таки инсталлятор используете?

Я это к тому что не надо путать виндовые привычки с удобным способом установки как бы он не был реализован.

>Ubuntu вы тоже вручную собираете или таки инсталлятор используете?

Заставь дурака Богу молиться, он лоб себе расшибёт.

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

А он в убунтушном репозитории есть?

В репах кармика есть.

>Нет, операционку я ставлю так, как ей подобает.

Так и остальные программы ставьте так как им (!) подобает... :)

> Хватит с меня меня виндовых помоек.

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

>и то что "за всеми системными файлами должна следить только операционка" никакого отношения в данном случае к делу не имеет. :)

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

>И да, в пресловутой "венде" таки отслеживаются инсталлированые пакеты, или уже не?

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

>>и то что "за всеми системными файлами должна следить только операционка" никакого отношения в данном случае к делу не имеет. :)

>Имеет. [...] Linux у меня на каждой машине ставится раз и на всю жизнь. И ставить какой-то софт, неподконтрольный системе - это иметь через год-пять-десять ненужный мусор.

Не понимаю почему для человека осилившего сборку gentoo это представляет какую-то проблему...

>>И да, в пресловутой "венде" таки отслеживаются инсталлированые пакеты, или уже не?

>Нет. Отслеживанием файлов занимается прикладной софт, а не система. И делается это там весьма черезжопно.

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

во-вторых, если отвлечься от того что "венда", что Вам конкретно не нравится?

>Gentoo - вручную, по хэндбуку.

Фу.

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

>Не понимаю почему для человека осилившего сборку gentoo это представляет какую-то проблему...

Потому что это никак не коррелирующие понятия. Можно срач развести и в Gentoo.

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

Windows не контролирует списки файлов. Этим занимается uninstall от приложения, который и запускает Windows. Инсталлятор регистрирует в системе деинсталлятор. Но не список файлов.

>во-вторых, если отвлечься от того что "венда", что Вам конкретно не нравится?

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

> А дальше - за всеми системными файлами должна следить только операционка и только своими средствами.

Ну а если эти средства в лялихе глючны, что вы делать будете?

http://www.linux.org.ru/view-message.jsp?msgid=4041799

>>Не понимаю почему для человека осилившего сборку gentoo это представляет какую-то проблему...

>Потому что это никак не коррелирующие понятия. Можно срач развести и в Gentoo.

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

>Windows не контролирует списки файлов. Этим занимается uninstall от приложения, который и запускает Windows. Инсталлятор регистрирует в системе деинсталлятор. Но не список файлов.

а как работает aptitude, сильно по другому?

что-то мне досказывает что ядру linux список установленных файлов тоже не сдался нифига... :)

>>во-вторых, если отвлечься от того что "венда", что Вам конкретно не нравится?

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

Так они и так системе "неподконтрольны", т.е. никто их не мешает снести, налить туда новых и "системе" будет пофик, не?

Потом почему в Gentoo этот вопрос Вас не смущает?

>Ну а если эти средства в лялихе глючны, что вы делать будете?

Не знаю. Не сталкивался.

>Пытаюсь установить glib 2.21 из исходников

Хм?

>а как работает aptitude, сильно по другому?

Совершенно по-другому. Он знает каждый системный файл.

>Потом почему в Gentoo этот вопрос Вас не смущает?

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

>>а как работает aptitude, сильно по другому?

>Совершенно по-другому. Он знает каждый системный файл.

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

Что я имею ввиду, так это то что каждая программа и так и так отвечает за себя, только в случае инсталлятора (в среде "венды") при установке, а в случае aptitude при создании конфига.

Правильно я понимаю?

>>Потом почему в Gentoo этот вопрос Вас не смущает?

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

А если то что нужно Вам нет, к примеру, в репозитариях? Не используете по идеологическим соображениям?

Представьте что Вам надо поставить python следующей версии сохранив как системный уже установленный, как Вы это сделаете при помощи той же aptitude?

Короче, у меня есть ощущение, что Вы чёт по "два презерватива надеваете".

>> Ну а если эти средства в лялихе глючны, что вы делать будете?
Не знаю. Не сталкивался.

А когда столкнётесь?


>> Пытаюсь установить glib 2.21 из исходников
> Хм?

Я кдешник...

>итак... получается никакой разницы нет

Для тебя разницы нет. На том и порешим.

>А когда столкнётесь?

Тогда и буду думать. Однако, учитывая, что в Windows я на протяжении 17 лет работы с ней сталкиваюсь с подобным регулярно, а за 6 лет сидения под Linux не сталкивался ни разу, полагаю, в будущем эта проблема под Linux будет для меня также малоактуальна.

>>итак... получается никакой разницы нет

>Для тебя разницы нет. На том и порешим.

ну не хотите - как хотите :)

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

механизм очень простой - есть общая помойка в registry.

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

Общего репозитория с описанием всех установленных файлов с указанием их контрольных сумм - нет.

Аналога gentoo qfile - нет.

>>поясните механизм

>Механизм очень простой - есть общая помойка в registry. И в этой помойке регистрируются программы. Каждая регистрирует себя как захочет. И еще каждая при установке прописывает программу установки/удаления/изменения конфигурации. Опять же каждая программа прописывает такой деинсталлятор, какой захочет.

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

>Общего репозитория с описанием всех установленных файлов с указанием их контрольных сумм - нет.

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

>Аналога gentoo qfile - нет.

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

>Нет. Отслеживанием файлов занимается прикладной софт, а не система.

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

>Ну во-первых, вы не правы - есть (правда такие средства не входят в состав системы).

Перестаньте обсуждать темы, в которых Вы совершенно не разбираетесь.

>Занимается этим вполне себе системная служба

И как же она зовётся? И почему же ею никто не пользуется, инсталлируя с каждой программой свой велосипед? Или ты про msi? Так это, дай, бог, 5% всего софта...

>>Ну во-первых, вы не правы - есть (правда такие средства не входят в состав системы).

>Перестаньте обсуждать темы, в которых Вы совершенно не разбираетесь.

ну, дорогой мой, мы с Вами же завершили кордебалет на сегодня, не?

и по теме, я сам использовал такие прикладные программы, когда возникла необходимость, и хотя у них есть ряд косяков, но они в автоматическом режиме отслеживали все устанавливаемые файлы и позволяли зачищать их при неправильной работе анинсталлера, причём отслеживались также перемещения/удаления/whatever файлов на дисках, таки учите матчасть - это хорошо для кармы!

>ты про msi? Так это, дай, бог, 5% всего софта...

статистка, статистика... а пруфлинк-то где?

сдаётся мне Вы не в теме :)

и кстати, вот почитайте малец (для общего развития):

http://xs-rus.ucoz.ru/publ/4-1-0-12

>>И да, в пресловутой "венде" таки отслеживаются инсталлированые пакеты, или уже не?

Если эти пакеты сами захотят, что бы их отслеживали... Нету в венде ни *.deb, ни *.rpm и ебилдов кстати тоже :)

>Если эти пакеты сами захотят, что бы их отслеживали...

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

>. Нету в венде ни *.deb, ни *.rpm и ебилдов кстати тоже :)

а я то удивляюсь, спасибо Кэп :)

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

О каких "пакетах" в windows вы говорите? И можно пруфлинки на эту "тулзу"?

> И да, в пресловутой "венде" таки отслеживаются инсталлированые пакеты, или уже не?

Плоховасто. Дело в том, что тамошние (популярные) инсталляторы представляют собой, по сути, программу, набор инструкций "что нужно сделать, чтобы взлететь". И да, средства регистрации одного отдельно взятого файла (теперь уже) есть, но на практике, выработанной годами и толпами паковщиков, возникает довольно много всякого, о чём знает только данный конкретный uninstall.exe. Или не знает...

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

ну да ладно! реестр, очевидно, для того и создан, чтобы в него гадили. но и с файлами не все так радужно - сколько раз встречались деинсталляторы, любезно оставляющие директорию Program Files\%PROGRAM NAME% с различным хламом внутри. это, видимо, на память, да? )

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

про никем не очищаемые C:\WINDOWS\Temp и %USERPROFILE%\Local Settings\Temp я уже молчу.

это какой-то ад, чесслово )

и да, сабж к черту. Qt наше все

> Ну а если эти средства в лялихе глючны, что вы делать будете?

Лечить голову. Потом исходники проблемного пакета. В общем, Ваш пример, мягко говоря, не убедителен.

> а как работает aptitude, сильно по другому?

Ы-ы-ы, да, сильно по-другому. велкам ту /var/lib/dpkg или где оно там лежит (у меня - /var/lib/rpm :) ).

> Так они и так системе "неподконтрольны", т.е. никто их не мешает снести, налить туда новых и "системе" будет пофик, не?

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

> Потом почему в Gentoo этот вопрос Вас не смущает?

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

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

>О каких "пакетах" в windows вы говорите?

программных канэшна :)

>И можно пруфлинки на эту "тулзу"?

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

>Плоховато.

кто бы спорил :)

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

да, как и make install впрочем

>И да, средства регистрации одного отдельно взятого файла (теперь уже) есть, но на практике, выработанной годами и толпами паковщиков, возникает довольно много всякого, о чём знает только данный конкретный uninstall.exe. Или не знает...

ога, всё так... согласен

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

Теоретически - да. На практике мои НЕкомпьютерные знакомые примерно раз в год-полтора производят переустановку винды, "потому что вирусы (как правило, трояны, подцепленные "в интернете" - прим. моё), тормозит и места свободного всё меньше". Объясняется тем, что _гибкость_ процесса инсталляции софта в винде редко полностью учитывается многочисленными анинсталлерами.

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

конечно слышал... когда "сидел под" регулярно пользовал... а где я говорил что "виндовые" инсталляторы - умнички?

>реестр, очевидно

реестр - очень странное (к тому же весьма спорное) решение, в котором отсутствует очень много правильных механизмов...

>про никем не очищаемые C:\WINDOWS\Temp и %USERPROFILE%\Local Settings\Temp я уже молчу.

да, да, да... скриптик

>это какой-то ад, чесслово )

да, но живут же люди

>>> Пытаюсь установить glib 2.21 из исходников >> Хм?

> Я кдешник...

Это, конечно, многое объясняет :) Смотрите, прибежит некто с цветастой аватаркой и нумерованным ником, заклюёт :)

В общем, решение Вашей проблемы - apt-get install glib (или как оно у вас там называется, справиться при помощи apt-cache search glib). Если так невтерпёж поставить версию, которой ещё нет в официальных репозиториях - ну, тогда apt-get source glib, чтобы получить заготовки предыдущей версии пакета для дебианоспецифичных файлов , а дальше - по инструкции для _честной_ сборки .deb'ок, там три или четыре пункта всего.

>>О каких "пакетах" в windows вы говорите?
>программных канэшна :)

Надо ли говорить, что есть разница между "программным пакетом" и пакетом данных приложения?

>к сожалению, на горячую найти не получилось...

Да я даже подскажу - http://en.wikipedia.org/wiki/Package_management_system
Только вот "пакетная система" - это нечто большее, нежели следилка за обновлениями. К тому же, под windows они охватывают только пользовательские приложения. Не говоря уж о куче других недостатков.

>>>О каких "пакетах" в windows вы говорите?

>>программных канэшна :)

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

мы же в обществе здоровых людей?

>Да я даже подскажу - http://en.wikipedia.org/wiki/Package_management_system

это не совсем то...

>Только вот "пакетная система" - это нечто большее, нежели следилка за обновлениями. Не говоря уж о куче других недостатков.

Вы, кстати, подняли правильную проблему... она, конечно, не относится к установке/удалению программ... но эти недостатки в "венде", вне всякого сомнения, обусловлены проприетарной моделью ведения бизнеса... под linux такой проблемы нет - вот и профит :)

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

ммм... может наоборот, системные?

> но эти недостатки в "венде", вне всякого сомнения, обусловлены проприетарной моделью ведения бизнеса... под linux такой проблемы нет - вот и профит :)

Нет, проприетарность здесь почти не при чём. Верьте мне, с моим участием паковался проприетарный софт под два десятка систем, включая фряшные порты и MacOSX. То, что при этом использовались стандартные средства этих систем (apt, up2date, yum, smart и порты) ничуть не мешало проприетарности распространяемого софта. Правда, конечно, накладывало определённые ограничения на процесс паковки.

>мы же в обществе здоровых людей?

Да?? А я думал это ЛОР.

>это не совсем то...

Ну да, о чем я и. Совсем то - это dpkg :)

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

Еще как относится. Изначальный тезис - "в windows нет вменяемых средств для слежения/управления файлами приложений". За исключением кривых "высокоуровневых" велосипедов. В результате чего образуется помойка, от которой спасет только переустановка. В линуксе таких проблем в общем случае нет.

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

Это обусловлено архитектурными причинами, мне кажется.

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

Я про то, что следить за файлами, собственно, системы нереально. Потому что тамошние "пакетные менеджеры" - костыльная надстройка для слежения за апдейтами квипов и фуррифоксов :)

>То, что при этом использовались стандартные средства этих систем (apt, up2date, yum, smart и порты) ничуть не мешало проприетарности распространяемого софта

Кстати, да.

> То, что при этом использовались стандартные средства этих систем

"при этом" - в процессе инсталляции и де-инсталляции. А ещё виртуозные темплиты, у vzyum'а тоже были свои, м-м-м, родимые пятна...

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

KRoN73> И ставить какой-то софт, неподконтрольный системе - это иметь через год-пять-десять ненужный мусор.

Ещё один не осилил назначение /usr/local

>> Ну а если эти средства в лялихе глючны, что вы делать будете?

> Лечить голову. Потом исходники проблемного пакета. В общем, Ваш пример, мягко говоря, не убедителен.

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

> Ну а если эти средства в лялихе глючны, что вы делать будете?

Использовать линукс, а не херню всякую.

>Представьте что Вам надо поставить python следующей версии сохранив как системный уже установленный, как Вы это сделаете при помощи той же aptitude?

Как назло, именно с питоном этот вопрос решается проще всего. Две версии прекрасно живут вместе.

>Представьте что Вам надо поставить python следующей версии сохранив как системный уже установленный, как Вы это сделаете при помощи той же aptitude?

Я лично использую в таком случае сырцы и просто собираю в отдельную папку. Насколько это удачное решение?

>>Представьте что Вам надо поставить python следующей версии сохранив как системный уже установленный, как Вы это сделаете при помощи той же aptitude?

>Как назло, именно с питоном этот вопрос решается проще всего. Две версии прекрасно живут вместе.

ну попробуйте... я попробовал в Gnome, после чего у меня перестало много чего запускаться из того что использует питон (типа диалога печати и т.д.) :)

потому как на установленную версию питона много чего налито (типа GObject etc.) и без повторного наката работать ничего не будет...

если же собрать питон отдельно и make install его в /usr/local/сами_решите_куда то всё хорошо и корректно работает и сносится кстати, тоже...

а вот если выполнить снос пакета в данном случае будет бо-бо

>ну попробуйте... я попробовал в Gnome, после чего у меня перестало много чего запускаться из того что использует питон (типа диалога печати и т.д.) :)
Интересно, как это у меня стоят две версии питона (2.6 и 3.1) и всё запускается? Да ещё и можно переключатся между ними.

btw, monodevelop 2.1.1 уже в основном дереве portage.

>Интересно, как это у меня стоят две версии питона (2.6 и 3.1) и всё запускается?

У меня на одной машине ещё недавно были 2.4, 2.5 и 2.6. Сейчас всюду один 2.6 остался. 3.x пока не требовался.

>>ну попробуйте... я попробовал в Gnome, после чего у меня перестало много чего запускаться из того что использует питон (типа диалога печати и т.д.) :)

>Интересно, как это у меня стоят две версии питона (2.6 и 3.1) и всё запускается? Да ещё и можно переключатся между ними.

Какая система, DE?

Вы ставили его через apt-get install python-blah-blah ?

>Какая система, DE?

Gentoo. DE при чём тут? Каждый Python в своём слоте.

>Вы ставили его через apt-get install python-blah-blah ?

emerge -av python:2.4 python:2.5 python:2.6 python:3.1

У меня в Дебиане три разных питона, поставлены все из репов. Gajim как работал, так и работает. ЧЯДНТ?

>>Какая система, DE?

>Gentoo. DE при чём тут? Каждый Python в своём слоте.

ну это в основном в гноме проявляется... :)

>>Вы ставили его через apt-get install python-blah-blah ?

>emerge -av python:2.4 python:2.5 python:2.6 python:3.1

понятно...

на самом деле должен попросить прощения, попытался воспроизвести ситуацию - нифига... видимо чего-то напутал со временем, сорри

я - туплю, не обращайте :)

>ну попробуйте... я попробовал в Gnome, после чего у меня перестало много чего запускаться из того что использует питон (типа диалога печати и т.д.) :)

Ну у меня уже так стоит. Запускается все, думаю, у вас причина в другом. Ибо не с чего (#! не зря придуман)

> Как назло, именно с питоном этот вопрос решается проще всего. Две версии прекрасно живут вместе.

У меня пять версий Питона установлено. И системная версия пашет без проблем.

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

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

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

>а как работает aptitude, сильно по другому?

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

>что-то мне досказывает что ядру linux список установленных файлов тоже не сдался нифига... :)

При чем тут ядро? Это нужно администратору. И ядро - такой же пакет о списком файлов и скриптом с вызовом mkinitrd и тому прописьюв меню груб.

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

Разница есть. Инсталлятор - программа, а пакет, это данные. Ошибок в инсталляторах, как и в makefile всегда навалом. Зачастую инсталлятор убивает весь корень, например, при выборе альтернативной директории для установки. Но пакет собирается от пользователя и ставит все в пустой DESTDIR, в то время как инстллятор работает от рута и свободно может испортить любой файл в системе.

>Что я имею ввиду, так это то что каждая программа и так и так отвечает за себя, только в случае инсталлятора (в среде "венды") при установке, а в случае aptitude при создании конфига.

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

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

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

Извини, но это тоже бред

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

В какой системе? В непонятном мне checkinstall ? Наверное.

Повторю ещё раз, медленнее: в Дебиане есть штатный метод установки нового софта. apt/aptitude называется. Тем, кто НЕ ПОНИМАЕТ, как работает система, следует пользоваться именно этим методом.

Для тех, кто, может, и не понимает, но хочет разобраться, есть

google://how to build debian package from sources

первые три-четыре ссылки. Есть даже официальное руководство на русском http://www.debian.org/doc/manuals/maint-guide/maint-guide.ru.txt

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

вообще-то это не архисложно :) если ты знаешь состояние файловой системы на момент до установки всегда можно позырить diff

>>а как работает aptitude, сильно по другому?

>сильно по другому. Есть список файлов,[...]

т.е. идеологически - никакой разницы, так?

>Ошибок в инсталляторах, как и в makefile всегда навалом. Зачастую инсталлятор убивает весь корень, например, при выборе альтернативной директории для установки.

ну что можно сказать - нефиг сидеть под рутами

>инстллятор работает от рута

накуя? это нужно в 5% случаев

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

посмотри скрипт и не парься :)

а потом, ты много видел инсталлеров под Linux? я видел из последнего Netbeans, QtCreator, Visual Paradigm... вроде всё

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

> т.е. идеологически - никакой разницы, так?

Под слаку все заманываете :)))
Идеологически есть разница - так есть контроль версий пакетов и их приоритетов на всех "уровнях".

>Идеологически есть разница - так есть контроль версий пакетов и их приоритетов на всех "уровнях".

конечно есть... :) но мы разговариваем в данный момент об инсталляции/деинсталляции и идеологической разницы - никакой, на мой взгляд... есть только 1 ньюанс, за инсталлятор отвечает только тот кто его накопипастил/завелосипедил, а aptitude она 1 такая и все ей пользуются, и это существенный ньюанс... но, блин, инсталлятор - это не такое зло как можно подумать и уж точно не windows-style, хотя это, конечно, моё личное мнение

> инсталляции/деинсталляции и идеологической разницы - никакой, на мой взгляд...

Именно ,что это на ваш взгляд...

for example
Логика:
мимо двух перцев проходит симпатичная барышня
>Ты с ней спал ?
- нет ...
> И я нет, вот же ж шлюха ...

:)))

>Именно ,что это на ваш взгляд...

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

ну не так же (реальный случай):

мимо двух перцев проходит симпатичная барышня

- (1) ты с ней спал ?

- (2) нет ...

- (1) и я нет, эх, вот спит же кто-то

- (барышня) да такой мудак как ты и спит

> а на чей ещё я должен взгляд ориентироваться?

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

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

так, наверное говорили и Эйнштейну :)

батенька всё что ковыряется можно ковырять и нужно ковырять - пробовать на зуб... так приобретаются ценные знания

> так, наверное говорили и Эйнштейну :)
> батенька всё что ковыряется можно ковырять и нужно ковырять

Вот Эйнштейн тут совсем не к месту - это был чистый теоретик.

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

> ... так приобретаются ценные знания

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

>Извини, но это тоже бред

в какой части? никогда не видел ошибок в апте? или в инсталляторах?

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

а никто и не сидит, речь про инсталляцию программ.

>накуя? это нужно в 5% случаев

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

>посмотри скрипт и не парься :)

во первых, скрипт занимает тысячи строк, во вторых, обычно он начинается с cat < con и дальше идет большой блоб бинарного инсталлятора.

А ошибка может быть в лишнем пробеле или отчего-то пустой переменной.

>а потом, ты много видел инсталлеров под Linux? я видел из последнего Netbeans, QtCreator, Visual Paradigm... вроде всё вот!

Слава БГ, их мало и лучше бы не было вовсе. Есть же вариант, как в макось. Папочку перетащил в хомяк и пользуйся. Зачем облекать тоже самое в эти вонючие визарды?

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

а их там кк раз до чертиков. И в линуксе будут, если благодушествовать.

1) установить/удалить программу с полной очисткой в общем случае нельзя. Не зря же придумали кучу деинсталляторов и клинеров реестра...

2)Скрипт деинсталятора лежит в программе. Удалил папку с программой - все, она уже недеинсталлируема (реестр, конфиги). Произошла ошибка в деинсталляторе - тоже самое.

>Вот Эйнштейн [...] был чистый теоретик.

быть того не может :)

>Хотя, прописные истины надо периодически подвергать ревизии :)) - может, свежий глаз увидит нечто новое.

именно :)

>"ценные знания" бывают одноразовыми

не уверен, к тому же пока не попробуешь - не узнаешь

>в общем случае предполагается, что программа ставится в систему.

вовсе и нет... вообще не трогай систему, максимум симлинки туда покидай

>Но и убийство хомяка тоже вещь неприятная...

но не такая страшная как снос системы целиком, правда?

>>посмотри скрипт и не парься :)

>во первых, скрипт занимает тысячи строк,

та часть что deploy делает гораздо меньше

>во вторых, обычно он начинается с cat < con и дальше идет большой блоб бинарного инсталлятора.

блоб, как понимаешь, можно не смотреть :)

>Зачем облекать тоже самое в эти вонючие визарды?

а ты нос зажмурь и мышкой, мышкой...

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

>а их там кк раз до чертиков.

>1) установить/удалить программу с полной очисткой в общем случае нельзя. Не зря же придумали кучу деинсталляторов и клинеров реестра...

это не проблема в данном случае, а побочный эффект, причём решаемый... проблема была бы если бы при установке или деинсталляции, к примеру, сносилась бы ОС или пользовательские данные...

>2)Скрипт деинсталятора лежит в программе. Удалил папку с программой - все, она уже недеинсталлируема (реестр, конфиги). Произошла ошибка в деинсталляторе - тоже самое.

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

Вы только не подумайте что я за windows тут агитирую.. просто я не понимаю почему создание инсталлятора является "чисто" виндовой практикой и не вижу почему бы и не воспользоваться если с умом

>вообще-то это не архисложно :) если ты знаешь состояние файловой системы на момент до установки всегда можно позырить diff

В дос? А линукс система многопользовательская и многозадачная.

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

>т.е. идеологически - никакой разницы, так?

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

>>вообще-то это не архисложно :) если ты знаешь состояние файловой системы на момент до установки всегда можно позырить diff

>линукс система многопользовательская и многозадачная.

бгггг... в /usr/bin ветра дуют??? или временные файлы скапливаются может?

>>т.е. идеологически - никакой разницы, так?

>идеологически разница в том, что пакет пассивен.

устанавливаемый пакет всегда пассивен, что там, что там, Вы путаете

>В то время как инсталлятор активен. Это некая программа, которая что-то делает. Может раскладывать файлы, а может делать все, что угодно...

как и aptitude, к примеру, не?

>но не такая страшная как снос системы целиком, правда?

вопрос. Система останется, а вот что будет с данными?

>блоб, как понимаешь, можно не смотреть :)

блоб, это инсталлятор и есть. Это не сама программа.

>это не проблема в данном случае, а побочный эффект, причём решаемый... проблема была бы если бы при установке или деинсталляции, к примеру, сносилась бы ОС или пользовательские данные...

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

Приходится ставить систему заново.

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

В линуксе из за пакетного менеджера проблем на порядок меньше.

>Вы только не подумайте что я за windows тут агитирую.. просто я не понимаю почему создание инсталлятора является "чисто" виндовой практикой и не вижу почему бы и не воспользоваться если с умом

Для какой-то одной программы, достаточно весомой и одновременно не влияющей на систему в целом - да. Например, это может быть openoffice или какой-нибудь xml-редактор.

Но для системы в целом это неприемлемо.

>устанавливаемый пакет всегда пассивен, что там, что там, Вы путаете

>как и aptitude, к примеру, не?

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

Инсталлятор каждый раз новый и пишется он каждый раз новой компанией.

Апт работает на уровне системы. Инсталлятор работает на уровне приложения.

> Это некая программа, которая что-то делает. Может раскладывать файлы, а может делать все, что угодно...

+1, никогда не доверю незнакомой софтине лапать свою ненаглядную ОС с рутовыми привилегиями