А зачем Kopete'у acl, gcc, gcc-g++, gtk+ (это K-приложению-то!), samba (вот уж что непонятно-то!), xmms (???). На моем насквозь rpm-based дистре ни одной из этих зависимостей у Kopete нет

"пути Патрека неисповедимы". Как же можно, без gcc в чате разговаривать то.

> Как же можно, без gcc в чате разговаривать то.

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

В конце концов берется последний образ от Патрека и ставится начисто. Правильно?

Нет, даже если нет желания обновлять через swaret или slapt-get, то всегда можно тупо upgradepkg. Отлично там всё обновляется

Ну и плюс у слаки есть охрененное преимущество - это очень быстрый дистрибутив. Патрик отменно собирает пакеты.

P.S. Сам сейчас Gentoo пользуюсь, до этого Ubuntu стояло. Слакой тоже долго пользовался, очень достойный дистр.

>В конце концов берется последний образ от Патрека и ставится начисто. Правильно?

В смысле цитирование забыл:)

>Ты лучше расскажи, как ты потом все это болото обновляешь, и как оно после этого работает. Умение набирать make install - сомнительный повод для гордости

Вы таки определитесь checkinstall или make install ? ;)

PS: "Болото" обновляется легко и быстро ;)

Вот это они совершенно напрасно встали в позу..

Ответы:
1) для удобной работы в слаквари он не нужен
2) видел часть в unsupported/slacktrack вроде
3) асилить ldd,sort,grep, если их не устаивает (1), и написать злосчастные 1.2кб shell-кода
4) асилить 3(грубо) команды, необходимых для создания слакварного пакета и записать их в отдельный скрипт:
"./configure --prefix=/usr",
"make install DESTDIR=[tmpdir]"
"makepkg [pkgname]-[pkgver]-1.tgz"

Ещё скажите, что написать deb или rpm-спеки проще.
---
5) Cудите по себе

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

1) Ну это как всегда..
2) Почему не стандартизовать и не сделать supported? Это принципиальная позиция, целенаправленно приводящая к выпадам со стороны разработчиков отдельных продуктов (типа gaim)? Я понимаю, что "см. #1" - но при таком подходе Патрику не за что обижаться на пиджонов.
3) В начальном условии стоит "ниасилил". Давайте не будем менять начальное условие?;)
4) Расскажите подробнее, как при подобной схеме сборки пакета отслеживаются зависимости? Особенно интересно если пакет не автотулзовый или кривоавтотулзовый. Надеюсь, Вы в курсе, что в наше время многие софтины мягко говоря, неоднозначно воспринимают DESTDIR (порой просто кладут на него)? Или все такие софтины эмоциональный Падрег сразу отсылает на свалку истории слаки (вслед за гномом, где такого софта особенно много, спасибо gconf и пр.)
Спеки deb/rpm действительно сложнее. Но зато там можно учесть гораздо больше вещей - включая зависимости. Как Вы думаете - почему нет проблем найти deb/rpm (и они часто доступны прямо на сайте проекта, как в случае с gaim) - и совсем непросто найти готовый tgz? Мой вариант ответа практически совпадает с последним вариантом товарищей из gaim.
5) Я сужу даже не по себе (сборку rpm я освоил, deb ленюсь), а по тем, кто еще тупее. Слака - для Элиты?

>Слака - единственный дистрибутив, который после установки работает без проблем.

Лично я на слаке не смог завести звук и атишную карточку. На демьяне всё работает без проблем (разве что lyx кракозабрами в меню пишет)

ИМХО просто пошло разделение в развитии. Комуто надо "сырцы и штоп пускалось", кому-то взаимоинтеграция вроде как чтоб приложение А и B могли использовать одни и те же ресурсы (записная книга, календарь и т.д.).

Чего в слаке нет и не будет. Точнее сделать можно, но скажем если в дебе можно безболезненно выбирать тот или иной набор софта (который будет успешно общаться), то в слаке прийдется собирать со всеми включенными опциями и высасывать весь репозиторий в противном случае гарантированы косяки вида "еклмепрст.so.1.2.3 not found"

переходи на венду. там уже есть единый формат пакетов

Потому что Патрик БОХ! Он знает, что сейчас чтобы тебя авторизовали в аське обязательно нужен gcc (всякие там ++i + ++i посчитать по-быстрому)

Интересно, какой? :)

Патрег ЛОХ и этим всё сказано.

jabber.el -- наше всё

> Кстати, сытная идея о том, как убить слаку...
Отступник! Патрик тебя покарает!

я бы его только из-за названия удалил

.msi

http://en.wikipedia.org/wiki/Windows_Installer

>Патрег ЛОХ и этим всё сказано.

Не судите по себе.

Pidgin, видимо, будет удален из Slackware

Интерессно если они осилили установку слаки то что говорить о установке openbsd и прочих bsd?

а мне все равно какой дистрибутив какой IM включит в себя. Вообще все равно. Надо все пробовать самому и выбирать лучшее. На то он и OpenSource...

А, допустим, MiKTeX, завернутый в пакет этого единого формата, где можно взять?

1) Почему-то все (кто тащится от других ПМ) думают, что слаке обязательно нужен аналог apt-get с -надцатью опциями, проверками зависимостей и пр. - они мне чем-то напонимают вендузятников с их желанием всунуть в линукс осла,аутпост и любимого касперского, ибо без подобных вещей они считают его "неполноценным и убогим"
2) KISS
3) и без него всё работает
4) installwatch,ldd,sort,grep - практически также, как и в rpm. Для "кривотулзовых" пакетов, для которых нет возможности отследить бинарные зависимости (конф.файлы, например) они пишутся вручную, как и везде.

>Я сужу даже не по себе (...), а по тем, кто еще тупее.

"Если ты самый умный, то кто это поймёт?"

>> Я знаком с ней чуть ближе - я с нее начинал.

> Наверное с 3.0 ? ;)

А что, до 3.0 жизни не было? Или теперь каждые 13 лет дистрибутив менять кошерно?

> Расскажите подробнее, как при подобной схеме сборки пакета отслеживаются зависимости?

Если руками то поставил, запустил, программа чётко написала что именно ей надо. Скачал это "что надо", поставил. Меня даже такой вариант устраивает больше чем то что наворотили в тех же RPM.

Вообще тот же swaret зависимости разруливает без постороннего вмешательства. Как и где эти зависимости прописаны - не вникал, если честно, и так как бы работает и есть не просит.

1) Я знаю, что слаке он не нужен. Как и слаководам. Я спрашивал про людей, не умудренных мудростью Падрега
2) Почему тогда не LFS?
3) Из коробки?
4) Вы серьезно думаете что, разработчики гейма ниасилили ldd/sort/grep? Ваша версия того, почему геймеры выкатили это заявление? Желательно не привлекая идею о всемирном заговоре против Патрега. Моя версия - наличие libabс.so.1.2 ничего не говорит о реальной версии пакета abc. А еще ничто не помешает поставить libabc.so.1.3 - и уже вряд ли кто сможет точно ответить (не глядя), куда указывает libabc.so. И поддерживать всю эту инфернальность геймерам нафиг не сдалось.

slackware. we embrace and promote dll hell.

> программа чётко написала что именно ей надо

Бугога. А если она открывает библиотечки "ручками", динамически (и молча завершается при необнаружении)? А если программа требует именно конкретную версию библиотеки (только не надо мне говорить про циферки после .so - я нарывался на то, что дисциплина их поддержки, мягко говоря, хромает - причем как со стороны разработчика приложения, так и со стороны разработчика библиотеки). Случай, когда программа явно ругается на отсутствие libabc.so.1.2 и готова работать с любым вариантом подобной библиотеки - СОВСЕМ не единственный. А в остальных случаях подход слаки тут же идет поперек борозды.

> Вообще тот же swaret зависимости разруливает без постороннего вмешательства.

Он является в слаквари таким же жестким и обязательным стандартом, как dpkg и rpm в debian/redhat?

> Случай, когда программа явно ругается на отсутствие libabc.so.1.2 и готова работать с любым вариантом подобной библиотеки - СОВСЕМ не единственный. А в остальных случаях подход слаки тут же идет поперек борозды.

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

> Он является в слаквари таким же жестким и обязательным стандартом, как dpkg и rpm в debian/redhat?

А зачем? Кому надо тот поставит.

> Случай, когда программа явно ругается на отсутствие libabc.so.1.2 и готова работать с любым вариантом подобной библиотеки - СОВСЕМ не единственный. А в остальных случаях подход слаки тут же идет поперек борозды.

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

> Он является в слаквари таким же жестким и обязательным стандартом, как dpkg и rpm в debian/redhat?

А зачем? Кому надо тот поставит.

> Не >= как положено, а строго, хотя работает с любой версией

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

> А зачем? Кому надо тот поставит.

Между "ему надо" и "он думает, что ему надо" - большая разница. И разница эта приводит как раз к тому, что разработчики софта кладут болт на слаку.

>А что, до 3.0 жизни не было? Или теперь каждые 13 лет дистрибутив менять кошерно?

Это вы к чему ? =)

>1) Я знаю, что слаке он не нужен. Как и слаководам. Я спрашивал про людей, не умудренных мудростью Падрега

Для "не джедаев" есть "some 3rd-party software tools" =)

http://en.wikipedia.org/wiki/Slackware#Package_management

>4) Вы серьезно думаете что, разработчики гейма ниасилили ldd/sort/grep?

Они (в данном конкретном случае) ниасилили _даже_ checkinstall ;)

>> А что, до 3.0 жизни не было? Или теперь каждые 13 лет дистрибутив менять кошерно?

> Это вы к чему ? =)

Странно, вроде кристально ясно съязвлено.

Потому, что это нужно не всем.

> Слака - для Элиты?

Кхм... Это что-то, вроде: есть автоматическая коробка, а есть ручное переключение...

Как, однажды, заявила одна моя знакомая (занимается лошадьми): "Мне нравится чувствовать живую груду мышц между ног." :-)

Причём здесь "Элита"?

>Странно, вроде кристально ясно съязвлено.

Но я йумора не понял ;)

Лично я на слаке не смог завести звук

# alsaconf

не осилил? :)

> и атишную карточку.

# X -configure

что именно?

>> Вообще тот же swaret зависимости разруливает без постороннего вмешательства.

> Он является в слаквари таким же жестким и обязательным стандартом, как dpkg и rpm в debian/redhat?

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

:-)

> Для "не джедаев" есть "some 3rd-party software tools" =)

То, что они 3rd party - говорит о том, что их нет. В смысле - на них нельзя рассчитывать.

> Они (в данном конкретном случае) ниасилили _даже_ checkinstall ;)

А Вы мало знаете пакетов, у которых поломан checkinstall? А uninstall. Да что там - даже distcheck в наше время уже совсем не везде проходит. Это реальность, она так выглядит.

> Кхм... Это что-то, вроде: есть автоматическая коробка, а есть ручное переключение...

Походу - при всей моей любви к ручному переключению, оно не жилец. Скоро, видимо, станет нишевой (имиджевой) фишкой. За него будут просить кучу бабла;)

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

Смотря от кого - от ОС или от женщины;)

>А Вы мало знаете пакетов, у которых поломан checkinstall? А uninstall. Да что там - даже distcheck в наше время уже совсем не везде проходит. Это реальность, она так выглядит.

Речь ведь про *конкретный* пакет ... или они там взялись решать _вселенскую_ проблему ?

>> А зачем? Кому надо тот поставит.

> Между "ему надо" и "он думает, что ему надо" - большая разница. И разница эта приводит как раз к тому, что разработчики софта кладут болт на слаку.

А их никто и не обязывает. Это их проблемы: сходу теряют часть пользователей.

Тут с ними полная гармония: они не хотят, а нам и не надо.

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

Что плохого в таком процессе?

http://www.linuxpackages.net/pkg_details.php?id=11015
Дискуссию можно закрывать? ;-)

>> Для "не джедаев" есть "some 3rd-party software tools" =)

> То, что они 3rd party - говорит о том, что их нет. В смысле - на них нельзя рассчитывать.

В дистрибутиве так или иначе 95% софта 3rd party ;)

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

> А их никто и не обязывает. Это их проблемы: сходу теряют часть пользователей.

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

> Что плохого в таком процессе?

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

>Они ничего не брались решать. Наоборот. Их задолбало решать конкретные проблемы конкретного пакета в конкретном дистрибутиве. При том, что в других конкретных дистрибутивах таких детскосадовских проблем нет. Другие - наверняка есть. Но, наверное, не столь задолбучие.

Может я чего не понимаю, но почему _разработчики_ должны решать проблемы _сборщиков_дистрибутива_ ? Какие бы проблемы там не возникали (касательно сборки) это не их дело. Или сейчас разработчикам модно выпускать пакеты сразу к >1000 (согласно distrowatch) дистрибутивам ? Вместо того чтобы посылать Патрега они бы лучше послали ендлузеров _К_ Патрегу.

> Неспособность Патрега договориться с апстримом - это в гораздо большей степени проблема Патрега (и его пользователей), чем апстрима.

Прошу меня простить, но кто такой Патрик -- я знаю много лет и ему доверяю, а кто такой сегодня апстрим персонально -- представляю с трудом (no personal: Вас, как разработчика Gnome немного представляю по L.O.R. :-), тем более не берусь загадывать, кто это будет завтра, послезавтра или через пол-года...

:)