SuSE Linux 7.3 теперь имеет свой apt-репозиторий

>Авель, я тот самый анонимус. Мне смешно видеть как ты считаешь себя
>самым умным.

рад бы. но здесь как раз все в порядке :)

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

по крайней мере, грамотно написано. :)

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

>А мне например требуется в ./configure настроить 10-15 параметров >которые в рпмках абы как заделаны.
кто мешает поправить спек? так и будем все в configure лазить по очереди и на одни и те же грабли наступать? какая от тебя польза обществу?

>Еще мне требуется держать по две-три версий одного проекта в разных >местах, накладывать и убирать на них патчи. Разве может этот apt-get >такое делать?
а uml на что? а чрут?
да ты и в правду слаб :(

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

Что сам пошутил, сам рассмеялся? Ну и пизди дальше с собой, не приставай к взрослым дядькам.

Avel Какой спек? Окстись! Что, мне с твоей точки зрения для копирования совершенно номальной программы с GNU конфигуре со спарка на PC мне нужно всякий бред городить с rpm apt-get и прочей мурой?

Мне гораздо проще сделать scp sun:/tmp/snapshot.tgz pc:/tmp/ А потом прывычные tar -x, configure, make...

А что подразумевалось под "а uml на что? а чрут?" Допустим мне надо посмотреть две версии апача, хули тебя так коробит от того что я соберу две разные версии в двух директориях при помощи того же make? Честно говоря, я не понимаю твоей упертости.

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

P.S. Специально для антифризов повторяю. Я не собираю весь дистрибутив компиляцией, предпочитаю все же ставит из rpm. Но вот ответственные вещи для некоторых серверов собираю исключительно вручную. Например samba со своими специфическими патчами, тот же bind или squid, вобще весь софт, который требуется резко обновить при обнаружении уязвимости, недожидаясь, пока неповоротливые вендоры дитрибутивов выпустят свои апдейты с некоторым опозданием. А так же фирменные наработки, которые ни один идиот не будет хранить в rpm, зная что оно может потребоваться на какой нить солярке.

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

>Мне гораздо проще сделать scp sun:/tmp/snapshot.tgz pc:/tmp/ А потом >прывычные tar -x, configure, make...

Ну-ну. А мне достаточно сказать apt-get install [program] и получить уже собранную версию программы (ага, без установки всех build-depends. Мсье на серверах держит все development libraries? Мсье тонкий извращенец?) под любой из 12 архитектур, на которых работает Debian.

>А что подразумевалось под "а uml на что? а чрут?" Допустим мне надо >посмотреть две версии апача, хули тебя так коробит от того что я

А три? А десять? Будешь делать /bin для каждой? Братан, man chroot.

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

Похоже на то. Просто потому, что того геморроя, который ты уже имеешь, тебе хватает.

>ответственные вещи для некоторых серверов собираю исключительно >вручную. Например samba со своими специфическими патчами, тот же >bind или squid,

И держишь на серверах весь набор средств, необходимых для сборки?? Библиотек, header'ов? Что ж у тебя за помойка-то там?

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

Надобно иметь нормальные дистрибутивы. Тогда "задержек" не будет. А если она и есть (как было с php4 в Debian, например), то я иду на development machine, накладываю там патч и собираю пакет, который потом легко ставлю на все сервера сразу. А ты, небось стал бы его на всех машинах пересобирать? Спорим, у меня получилось бы быстрее, секюьрный ты наш? А, я понял!!! У тебя один сервак, да??

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

О, мсье сам ищет дырки и затыкает их за неделю до публикации? Мсье крутой хакер? Может быть, мсье работает в CERT? Или тайный модератор bugtraq?

Вобщем, уважаемый, как завещал великий Ленин, "учиться, учиться и еще раз учиться..".

--
wart

Удручает, до чего же застолбили в наши головы со времен совдепии необходимость выработки только одного и "правильного" для всех понятия и решения, а ведь у каждого могут быть и разные цели и пути к ним. Еще более удручает, что на форуме столь уничижительно и остервенело бьют друг друга по самым уязвительным местам да как можно больнее, а ведь речь идет о расширении возможности дистрибутива SuSE. Разве это повод выклевывать глаза друг другу? camomile

> bash-2.04# mkdir shitdir
> bash-2.04# touch ./shitdir/shitfile
> bash-2.04# rm ./shitdir -R rm: ./shitdir: is a directory rm: -R: No such file or directory

Как насчёт попробовать прочитать man rm, man chown?
Hint: chown -R ...; rm -{r,R} ...; -- options must be _before_ the rest of arguments

RTFM про rpm и apt-get, урод. Развелось, блин, кульхацкеров... ./configure; make; ... А подчищать за тобой дерьмецо кто будет? Ты на мой вопрос не ответил, предпочёл оттявкаться. Ну так тявкай в сторонке, кульхацкер, не смеши умных дядек.

Avel оказывается на юниоре сидит... Ламерском дистре, который сделали для тех, кто только что с ветки, пардон, с винды слез. А вообще все это не надо. Правильно софт ставить только из сырцов и никак иначе. А RPM вообще гамно известное.

а в mandrake-russian уже давно говорят, что ходить на лор стало просто постыдной потерей времени.
правы они, конечно.
но все равно отдавать этот сайт на откуп полудуркам тоже неприемлимо.
так что терплю и всем местным грамотным людям желаю терпения и спокойствия...

Avel, тебе бы самому терпения пожелать. Хер с ним, rpm и компания может и прогрессивно (сам свой софт в rpms пакую), но презирать безумно портируемый и настраиваемый autocоnf не есть умно. Честно скажу - спорить с виндузятниками о линуксе у вас получается лучше, чем спорить с линуксоидами о линуксе -)))

P.S. Тем, кто вопит, что ./configure за собой не подчищает - дык на то make uninstall есть. Если автор проги не криворук, то список устанавливаемых файлов ему все равно придется прописать _самому_, что в Makefiles.in, что в spec-файле. Принципиальной разницы я тут не вижу.

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

Avel, местные грамотные люди желают вам научиться писать слово "неприемлeмо" более прямо, нежели в вашем варианте :)

>но презирать безумно портируемый и настраиваемый autocоnf не есть умно.
а кто его презирает? причем здесь autoconf? в 99% рпмок он сидит внутри и очень кстати упрощает процесс сборки.
Если тебе необходим именно тарбол и не подходит аналогичный рпм или деб - объясни, почему, а не кидайся пальцами. Я сам могу придумать кучу ситуаций, где рпм не проходит, но все эти ситуации не касаются абсолютного большинства никаким боком. стало быть - нет причин заявлять о каком то там "загнивании" от рпм.

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

>P.S. Тем, кто вопит, что ./configure за собой не подчищает - дык на >тоЮ make uninstall есть.

это не есть удобно, потому как после make install обычно идет rm -rf ~/buildtree/proga
так что искать потом эту цель весьма тяжко.
к тому же под "дерьмецом" можно понять и простую ситуацию - видим файл и предполагаем, что это то самое невычищенное "дерьмецо". как узнать правду? rpm -qf /подозреваемый скажет, чей он на самом деле, а у вас?


>Если автор проги не криворук, то список устанавливаемых файлов ему
>все равно придется прописать _самому_, что в Makefiles.in, что в
>spec-файле. Принципиальной разницы я тут не вижу.

в случае с рпм вся эта информация лежит в общей БД и используется для тысячи и одной надобности.
примитивное:
"не пересекается ли то, что я хочу поставить с уже установленным по файлам? по смыслу?"
"Какие файлы присутствуют в данном пакете?"
"Какие пветы или чужие файлы необходимы ля работы данного пакета"
"Что вообще стоит у меня в системе"
"зачем нужен данный пакет?"
"кто автор и какова лицензия на данный пакет?"

Так что никаких войн. Давайте просто уточнять свои позиции...

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

"но все равно отдавать этот сайт на откуп полудуркам НЕЛЬЗЯ."

но зато теперь я вижу, что грамотные люди здесь есть! :)

2Avel. Ну, в общем-то, можно взять, к примеру, Slackware. У него все пакеты в tgz, но это никак не мешает делать updatepkg, removepkg, installpkg. Единственное, это нет проверки зависимостей, да и ту в новых версиях уже готовят.

А вот почему tgz удобнее RPM дык это просто. Antihrist уже говорил (а в этом треде сам себе противоречит :-) tgz можно посмотреть "где угодно" хоть на Макинтош, а вот RPM фиг. С tgz гораздо проще работать. Например все мои локальные (и системные) настройки лежат в tgz который периодически обновляется.

А те приложения которые ставлю ./configure --prefix=.... && make && make install тоже все хорошо. Ставишь в папку /usr/local или /opt/kde2 или /opt/gnome и генеришь пакет tgz.

Все! легко теперь можешь проверить какой файл принадлежит какому пакету. Могу удалить легко. И к тому же имею свой репазиторий пакетов. Так что при установке с нуля системы. Достаточно скормить инсталяшке список установленных пакетов и все установится + все настройки будут установленны.

Удобно.

P.S.
А вообще в чем спор? Кто к чему привык, на каком дистре сидит тем и пользуются.

Я сам иногда пользуюсь RPM правда чаще всего в виде: rpm2tgz :^)

>2Avel. Ну, в общем-то, можно взять, к примеру, Slackware. У него все
>пакеты в tgz, но это никак не мешает делать updatepkg, removepkg,
>installpkg. Единственное, это нет проверки зависимостей, да и ту в
>новых версиях уже готовят.
вот в этом они и не правы, по моему.
сделав действительно легкий дистр, они теперь обвешивают его этими tgz базед рпмами и, по сути, изобретают велосипед уже в третий раз.

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

>> 2Avel. Ну, в общем-то, можно взять, к примеру, Slackware. У него все
>> пакеты в tgz, но это никак не мешает делать updatepkg, removepkg,
>> installpkg. Единственное, это нет проверки зависимостей, да и ту в
>> новых версиях уже готовят.
> вот в этом они и не правы, по моему.
> сделав действительно легкий дистр, они теперь обвешивают его этими tgz > базед рпмами и, по сути, изобретают велосипед уже в третий раз.
Сложно согласиться. Велосипед не изобретают это раз. Во вторых что _более_ легкое чем tgz можешь придумать к этому легкому дистру???? ИМХО наиболее оптимальное решение.
Единственного репозитария на все дистры не получится. Уж больно структурой отличаются, да в что тогда останется от дистров??? Если, по сути все они одинаковые (программы берутся ведь из одних и тех же источников) отличие: инсталлятор, начальные настройки, системы пакетов, структура каталогов.

(1) tgz отлично подходит для операций с каждым пакетом по-отдельности, в кодах или бинарным, но для работы с чистыми бинарниками или с множеством пакетов требуются дополнительные средства или индивидуальная само-дисциплина, которые сам формат ничем поддержать не может. Зато полная универсальность, кроссплатформенность, etc...

(2) rpm полностью наследует функции tgz (кому не понятно как и почему - пусть с помощью mc enter'ом внутрь rpm'ок и srpm'ок зайдут и посмотрят!), но добавляет следущий уровень функциональности - управление совокупностью пакетов (c учетом зависимостей и с системными скриптами pre-install и post-install), раз, и два, позволяет отрывать бинари от сырцов без потери качества управления, что вытекает из задач дистрибутостроения и сопровождения. Но кросс-системность во многом утрачивается...

(3) apt4rpm снова добавляет функционала - для получения-инсталляции-обновлении rpm-based системы можно пользоваться не одним, вручную определенным источником пакетов, а СРАЗУ несколькими репозиториями разного типа со свойственными им методами доступа, c возможностью создать и поддерживать свой репозиторий, да ещё и совершать все эти дейcтвия в автоматическом режиме.

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

src.tgz - для программиста и частных решений;

rpm - для дистрибуторства и _общих_ задач;

apt - для _инфраструктуры_ линукса;

deb и ports понятно похожи, но специфичны для подхода или системы.

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

speer отлично сказано

Нафига SuSE баян? Они дистры пекут как блины, все покупают новую коробку. Развели ля-ля на пустом месте

>Как насчёт попробовать прочитать man rm, man chown?

Casus, ты точно оправдал свое название. Сам себе придумал вопрос, сам на него ответил, почувствовал себя очень умным.

А как насчет того, чтобы теперь вникнуть в суть вопроса? Hint почему на linux -R работает, а на BSD - нет. И кто виноват?

Вперед, читать маны!

2Avel. Ты где свои 200 линуксов в месяц инсталируешь? Уж не сборщиком ли ты на формозе работаешь?

А про такую команду слышал? dd if=/dev/hda of=/dev/hdc

>Ты где свои 200 линуксов в месяц инсталируешь? Уж не сборщиком ли ты на формозе работаешь?
:)))
а там на конвейере линукс ставят? последний раз, когда был в магазине в районе китай-города, там про линукс слыхали, но msi дистр зажали.


>А про такую команду слышал? dd if=/dev/hda of=/dev/hdc
а про то, что версии каждый день меняются? а что компы разные? а список пакетов разный? может, мне их нортоном гхостом клонировать? :) а пересобрать пакетики?
это не тупая виндоза. здесь интересен тонкий интелектуальный профессиональный тюнинг, а не посекторное копирование.