Хочу для себя вопрос прояснить, нужны ли зависимости. На ЛОРе поднимать тему.. :-) ну вы сами понимаете.. Итак, что я имею с зависимостями: отсутствие гиммороя с установкой софта. Что вы имеете без зависимостей: наличие гиммороя с непонятками ч╦ за либа нужна для софтины. Нет, есть, конечно, такая вещь как опыт, т.е. знаешь ч╦ чему надо и ldd. Но, гимморой, Господа!
best regards..
in hack we trust.

На домашней машине, или даже сервере, который "твой". Отсутствие зависимостей не проблема, т.к. ты их систему знаешь вдоль и поперек, если знашь конечно. Если имеется несколько серверов, еще и разных, то зависимости значительно облегчают жизнь (установка,обновления). То же и с новичками, которые не знают, что им нужно и постоянно ставят что-то новое.
Кстати, swaret зависимости в слаке поддерживает как раз по необходимым библиотекам.
---
Ха, это тебе не сфинкс - чуть что сразу в воду... (2:463/51.36)

Ты хочешь сказать, что, к примеру, при установке гнома, легко все зависимости помнишь?
А что за негативные отзывы о н╦м звучали, он ограничен в ч╦м-то?
best regards..
in hack we trust.

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

Не помню, потому и не устанавливаю, те огрызки которые есть поставлены swaret по вычисленным зависимостям.
Негативные отзывы о чем?
---
DOS never says "EXCELLENT command or filename"... (2:50/502.37)

Да на ЛОРе где-то прочитал, там про swaret как-то так выразились, что он какой-то недоделаный. Ладно, это из серии "Одна бабка сказала".. Посто скажи, оно имеет недостатки какие-нибудь?
best regards..
in hack we trust.

Недоделаным все что угодно назвать можно. Недостатки есть, вон Chef, узнавал, как посмотреть состав неустановленного пакета, сварет этого не может. Хотя наверняка есть скрипт который может обрабатывать MANIFEST, содержащий список пакетных файлов. По простому вообще: grep ... MANIFEST.

Мне его функциональности хватает, что бы иметь стабильную, рабочую систему. Обновлена тем же сваретом с 9.0 до 10.0, а точнее синхронизируется с current.
---
98% каннибалов умирают от недоедания в возрасте до 9 лет (2:5054/4.2)

на ЛОРе читал - не от ника norden случайно? Это я и есть, я это и гвоорил про сварет. Он в принципе доделанный, но нет у него некоторых фих как например у апт-гет из дебиана. Апт-гет ищет по пакетам по принципу поисковой машины. Т.е. при составлении дебиан пакета нужно делать к нему длинное и короткое описание. А кроме того индексируется даже файловый состав пакета. Таким образом, к примеру, по одному только файлу из какого-нибудь пакета я могу найти сам пакет и все пакеты, которые с этим файлом имеют что-то общее. Или вот:
apt-cache search mp3 player выдает:
---8<-----------------
digitaldj - An SQL based mp3 player front-end
flac - Free Lossless Audio Codec - command line tools
gnomp3 - An MP3 player for large MP3 collections
gstreamer-misc - Collection of various GStreamer plugins
iripdb - Generates the DB files for the iRiver iHP-1xx
irmp3 - A Multimedia Audio Jukebox application.
juk - music organizer and player for KDE
knapster2 - A KDE clone of the windows Napster client
ksmp3play - Curses-based MP3 player
libalsaplayer-dev - PCM player designed for ALSA (interface library, development files)
libalsaplayer0 - PCM player designed for ALSA (interface library)
libflac++-dev - Free Lossless Audio Codec - C++ development library
libflac++2c102 - Free Lossless Audio Codec - C++ runtime library
libflac-dev - Free Lossless Audio Codec - C development library
libflac4 - Free Lossless Audio Codec - runtime C library
libmp3hip-dev - HIP Isn't a Player development library
libnjb-dev - Creative Labs Nomad Jukebox library
libnjb0 - Creative Labs Nomad Jukebox library development files
liboggflac++-dev - Free Lossless Audio Codec - C++ development library (ogg)
liboggflac++0c102 - Free Lossless Audio Codec - C++ runtime library (ogg)
liboggflac-dev - Free Lossless Audio Codec - C development library (ogg)
liboggflac1 - Free Lossless Audio Codec - runtime C library (ogg)
libsmpeg-dev - SDL MPEG Player Library - development files
libsmpeg0 - SDL MPEG Player Library - shared libraries
madplay - MPEG audio player in fixed point
moosic - Daemon/client combo to easily queue music files for playing
mp3blaster - Full-screen console mp3 and ogg vorbis player
mp3gain - Lossless mp3 normalizer with statistical analysis
mp3kult - Organizes your MP3 collection in a MySQL database
mpeglib - mp3 and mpeg I video/audio library for linux
-------------8<-----------------
это тока вырезка, список еще больше раза в два. Т.е. как видишь - все это пакеты, связанные с этими словами... Удобно очень. В сварет такого нет.

swaret тоже может искать в description, не только по имени пакета, но и по описанию
---
Брейся, не брейся - на елку все равно не похоже (2:5095/20)

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

А что именно в организации rpm не нравится?
best regards..
in hack we trust.

...и в политике Дебиан? :)

ААА! Вдвоем на одного!
Я пользовался когда-то redhat, сильно мешало то, что авторы пакетов прописывали ненужные на мой взгляд зависимости, что вело к установке ненужных мне пакетов, конечно rpm -f никто не отменял, но это как-то "не аккуратненько". Потом разочаровался в содержимом дистрибутива, мне хотелось вещей поновее, а они не появлялись. Дебиан не пошел опять же из-за желания иметь софт поновее, но unstable показал себя действительно нестабильным, был пример и с вообще неработающим пакетом, точнее пустым. Не сложилось.
---
Я, например, зла никогда не помню, но хату спалить могу (2:5010/177)

rh убогая система. из всех дистрибутивов они единственные, кто позволяет себе править (как они считают - улучшать) пакеты. посему зависимости у них крайне витееватые.
кроме того ставить бинарник имеет смысл при наличии тяжелых проблем (например trafshow под rh не собирается - выяснять себе дороже), в остальных случаях правильнее собирать из source, подправив ключи компиляции. 99% всех зависимостей вылезут на шаге ./configure. однако этот путь тоже до определенного момента. если есть необходимость переставить glibc - проще взять свежий дистрибутив.

Извини, конечно, я в Линуксе нович╦к, что бы спорить с гуру :-) , но объясни мне тайный смысл, на кой мне компилить вручную ту хренову тучу пакетов, что в дистрибутив входят? (Которые, кстати, уже скомпилены под мой процессор)
best regards..
in hack we trust.

Да!, в том числе ушел из-за гцц 2.96.
---
Женщина-сpедство пеpедвижения по спиpали Эволюции.(2:490/26.2618)

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

для того что бы быть уверенным в том, что ставишь. или ты полон доверия к rh? кстати последователи их, fedora, похоже на том же сучке сидели.
и если даже все это собиралось на rh и под rh, нет никакой гарантии, что в систему не было привнесено чтото более позднее/ранне/не относящееся к делу, которое может вылезти, хорошо если в core, а то ведь просто не запустится или повеселить странной работой.
откуда такое доверие к собранному бинарнику? кто знает о чем думал майнтенер когда собирал его? о чем думали люди из rh когда собрали 8 версию, где для сборки любого пакета было необходимо устанавливать CFLAG с путем к kerbros?
железный довод - при компиляции ты получаешь бинарник полностью учитывающий твою систему.
кстати - там где начинается куча зависимостей - это верный признак того, что пора менять дистрибутив на более свежий, поскольку новые версии все равно не идут под старые дистрибутивы. чуть сдвинулся glibc и все.

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

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