Просмотр полной версии : Gentoo Linux
Некоторое время использую Дженту... Очень нравиться этот дистрибутив. Имхо, самый простой и производительный дистрибутив. Очень гибок в настройке - благодаря манипуляциям с переменной USE (что позволяет включать/исключать из собираемых пакетов нужные/ненужные зависимости).
Также благодарая утилите Deltup обновление до пакетов последних версий будет стоить гораздо дешевле, чем в дебиане =). А также еще некоторая оптимизация под архитетуру машины...
Конечно, для установки пакетов в Дженту требуеться больше времени (время на компиляцию), но я даже не обращаю на это внимания :D
P.S. может быть я в чем-то повторяюсь...
Также благодарая утилите Deltup обновление до пакетов последних версий будет стоить гораздо дешевле, чем в дебиане =)
Ох уж эти сказочки, ох уж эти сказочники.
она что, бинарники дельтапит?
Или даже если исходники, неужели кто-то будет делать дельту, скажем, с KDE 3.5.6 до KDE 4.0? Если нет, то в чем дешёвизна-то? То, что мне нужно будет скачать 100 MiB бинарных готовых к работе deb-пакетов KDE 4.0, или в gentoo столько же исходников/бинарей?
Ох уж эти сказочки, ох уж эти сказочники.
она что, бинарники дельтапит?
Прости за непонимание, но при чем тут бинарники? я про них ни слова не сказал
Или даже если исходники, неужели кто-то будет делать дельту, скажем, с KDE 3.5.6 до KDE 4.0?
Вообще-то, дельта-пакеты автомотически генерируються специальным сервером (dev.gentooexperimental.org). Мне нужно только отправить корректный запрос (этим-то и занимается утилита Deltup), и подождать пару минут пока генерируется патч, если он еще не был сгенерирован ранее.
То, что мне нужно будет скачать 100 MiB бинарных готовых к работе deb-пакетов KDE 4.0, или в gentoo столько же исходников/бинарей?
Скорее всего у меня будет выбор: либо качать 100М исходников, либо 90-100М патча, не могу сказать точно, поскольку не знаю, что всетаки будет представлять из себя kde 4.0. Но зато для последующего обновления, предположим с KDE 4.0 до KDE 4.0.1-r1, мне потребуеться скачать лишь крохотный патч
Прости за непонимание, но при чем тут бинарники? я про них ни слова не сказал
ну мало ли, может уже и бинари дельтой дельтапят, я не в курсе. :)
Вообще-то, дельта-пакеты автомотически генерируються специальным сервером (dev.gentooexperimental.org). Мне нужно только отправить корректный запрос (этим-то и занимается утилита Deltup), и подождать пару минут пока генерируется патч, если он еще не был сгенерирован ранее.
ok. Т.е. если попросить, дельту kde 3.5.6-4.0.0, пусть и сверхтолстую, от него получить можно?
Скорее всего у меня будет выбор: либо качать 100М исходников, либо 90-100М патча, не могу сказать точно, поскольку не знаю, что всетаки будет представлять из себя kde 4.0.
Ну тогда для справки: официальные дельты KDE Project делаются только для снапшотов и минор-релизов. Именно потому, что с мажора до мажора дельты получатся больше, чем исходники в оригинале.
Но зато для последующего обновления, предположим с KDE 4.0 до KDE 4.0.1-r1, мне потребуеться скачать лишь крохотный патч
минор-апдейты - это уж на любителя и лекарство от нечего делать. Собирать дцать часов тот же kde/gnomoe/firefox/openoffice.org только потому, что обновил его за счет "крохотного патча" - это уже маразм. :)
ok. Т.е. если попросить, дельту kde 3.5.6-4.0.0, пусть и сверхтолстую, от него получить можно?
Именно. Теоретически я могу получить даже патч OpenOffice-kde :), только не вижу смысла такой ерундой заниматься.
Ну тогда для справки: официальные дельты KDE Project делаются только для снапшотов и минор-релизов. Именно потому, что с мажора до мажора дельты получатся больше, чем исходники в оригинале.
Не могу согласиться, но и спорить не буду. Я лучше подожду KDE 4.0 и обновлюсь. Тогда посмотрим кто прав :) (Надеюсь что я :) ).
минор-апдейты - это уж на любителя и лекарство от нечего делать. Собирать дцать часов тот же kde/gnomoe/firefox/openoffice.org только потому, что обновил его за счет "крохотного патча" - это уже маразм. :)
Во первых, новые версии просто так не выпускаются... обычно в них исправляют ошибки, уязвимости и прочие нехорошие свойства крупных проектов. Следовательно возможность дешево обновиться до последней версии - отнюдь не "лекарство от нечего делать"
Во вторых, даже на моем ведре сборка kde с НУЛЯ занимает всего 13 часов (gnome - 6ч, xfce - 2ч, firefox - 15мин, openoffice - 4ч), а из-за небольших обновлений весь пакет не будет полностью пересобираться. Обновиться лишь та часть которая подверглась изменениям.
P.S. Развели тут оффтопик... нехорошо
P.S. Развели тут оффтопик... нехорошо
Да, ладно нормально.
eleet, а вы поподробнее опишите как производятся такие обновления, в смысле не че нажать надо, а технологию. А то я что-то не догоняю. Для бинарников на системах типа Gentoo, FreeBSD такого не сделать, уж слишком сильно отличаются бинарники у конечных пользователей. Для архивов исходников тоже не покатит. Остаются только патчи к исходникам старой версии, которые возможно генерируются на каком-то сервере, архивируются, доставляются вам, затем патчатся ваши старые исходники и происходит сборка уже их пропатченных. Я правильно понимаю?
а из-за небольших обновлений весь пакет не будет полностью пересобираться. Обновиться лишь та часть которая подверглась изменениям.
А вот об этом можно еще по подробнее?
P.S. А вообще весь этот разговор можно вынести в отдельную тему касающуюся Gentoo.
XeNoN, вы абсолютно правы.
Программы в Gentoo Linux устанавливаются из исходни ков. Это чистый текст. Утилита Deltup просто скачивает со специального сайта не весь архив программы, а только разницу между требуемой версией и тем, что у вас есть. На этом спец. сайте имеются все пакеты, которые доступны с официального дерева. Следовательно, если я хочу обновиться с openoffice-2.0 до openoffice-2.1, то emerge (утилита для работы с системой портов, аналог apt) пытается скачать с сервера патч openoffice-2.0-openoffice-2.1.dtu. Сервер проверит наличие этих версий и сделает примерно следущее: deltup -m openoffice-2.0 openoffice-2.1 openoffice-2.0-openoffice-2.1.dtu # создаеться патч
emerge получит этот патч и выполнит действия:
deltup -p openoffice-2.0-openoffice-2.1.dtu # применяет патч Таким образом в системе появиться пакет нужной версии.
#В Дженту этот процесс автоматизирован.
Из-за небольших обновлений весь пакет не будет полностью пересобираться, т.к. крупные проекты обычно состоят из нескольких сегментов. Как правило изменяеться один-два таких сегмента, которые и будут пересобраны.
P.S. А вообще весь этот разговор можно вынести в отдельную тему касающуюся Gentoo.
И с этим я тоже полностью согласен
Из-за небольших обновлений весь пакет не будет полностью пересобираться, т.к. крупные проекты обычно состоят из нескольких сегментов. Как правило изменяеться один-два таких сегмента, которые и будут пересобраны.
Это при условии, что вы не чистите исходники после компиляции, т.е не делаете операцию подобную make clean?
А иначе любое изменение чистых исходников все равно потребует полной перекомпиляции.
XeNoN, вот именно. :) а еще надо умудряться это добро все хранить от компиляции к компиляции. По мне так, больше заморочек, чем вкусностей и приятностей.
Да и насчет сборки OOo на "ведрах" за 4 часа у меня большие сомнения. :)
Это при условии, что вы не чистите исходники после компиляции, т.е не делаете операцию подобную make clean?
А иначе любое изменение чистых исходников все равно потребует полной перекомпиляции.
Ошибаетесь, утилита emerge автоматически выполняет чистку после компиляции. Вам незачем хранить временные файлы.
Вообще, то что обновление до более новой версии происходит быстрее чем сборка с нуля - заслуга людей пишущих ebuild'ы.
Конечно это не всегда так... Я уже писал когда-то, что скорость установки пакетов - не являеться положительной стороной дистрибутива (Если конечно вы не используете уже готовые бинарные пакеты).
#Обычно я ставлю что-нибудь крупное на компиляцию и ложусь спать.
P.S. rmn, зря вы так отзываетесь о моей системе. Я же не говорю что Debian плохой дистрибутив только потому, что я его никогда не использовал
Ошибаетесь, утилита emerge автоматически выполняет чистку после компиляции. Вам незачем хранить временные файлы.
Вообще, то что обновление до более новой версии происходит быстрее чем сборка с нуля - заслуга людей пишущих ebuild'ы.
Конечно это не всегда так... Я уже писал когда-то, что скорость установки пакетов - не являеться положительной стороной дистрибутива (Если конечно вы не используете уже готовые бинарные пакеты).
Если выполняется чистка, то за счет чего сборка-то ускоряется? Мне это вот тоже непонятно. Вот хочу я, скажем, новую версию linuxdcpp поставить. За счет чего она при обновлении с нуля соберётся быстрее-то, можешь объяснить?
P.S. rmn, зря вы так отзываетесь о моей системе. Я же не говорю что Debian плохой дистрибутив только потому, что я его никогда не использовал
я помимо debian еще много чего использовал и делал :) Да, на gentoo всегда косо посматривал и не пользовался, потому что-то никто из его пользователей никогда до конца всю прелесть этого дистра не обрисовал. А качания и сборки софта по каждому чиху - это меня не прельщает. :)
#Обычно я ставлю что-нибудь крупное на компиляцию и ложусь спать.
:lol: а я предпочитаю спать в тишине ;)
а я предпочитаю спать в тишине
Не согласен, спать нужно под dead metal!!! :)
Ну или хотя бы под Чайковского в полгромкости на двадцативаттных колонках...
PS. Я рад что научился пользоваться оффтопик mode!
Если выполняется чистка, то за счет чего сборка-то ускоряется? Мне это вот тоже непонятно. Вот хочу я, скажем, новую версию linuxdcpp поставить. За счет чего она при обновлении с нуля соберётся быстрее-то, можешь объяснить?
Ладно, предположим я хочу обновиться с linuxdcpp-20061012 до linuxdcpp-20070403 (хотя в этом случае нету практически никакого ускорения сборки, т.к. пакет очень маленький - всего 328Kb.)
Версия 20061012 отличаеться от 20070403 тем, что первой не хватает некоторых файлов, и несколько десятков имеют разную дату изменения. Так вот, утилита make сама соберет только эти файлы и те которые от них зависят напрямую. А остальные уже были собраны ранее...
P.S. не совсем понял что ты имеешь ввиду под "обновлением с нуля" :blink:
eleet, ну, во-первых, как собирает проект make я представляю. :) во-вторых, в linuxdcpp не используются gnu autotools, но не в этом суть. В-третьих, linuxdcpp маленький, да удаленький. :) Там C++ код и сборка этих "всего 328 KiB" занимает почти 4 минуты на P4 2.4GHz И чудо-ускорение, которое я ожидаю от чудо системы сборки в gentoo, должно проделывать ту же сборку при обновлении с нуля исходников программы ну хотя бы за минуту.
Под обновлением с нуля я имею в виду то, что прошлая сборка была завершена удалением всех объектных файлов (потому что я не хочу хранить до следующей сборки уже не "всего 328 KB", а мегабайтов 5 объектников, пусть даже в архиве). Собственно, я про это:
Ошибаетесь, утилита emerge автоматически выполняет чистку после компиляции. Вам незачем хранить временные файлы.
Вообще, то что обновление до более новой версии происходит быстрее чем сборка с нуля - заслуга людей пишущих ebuild'ы.
eleet, ну, во-первых, как собирает проект make я представляю.
rmn, я был в этом уверен и поэтому привел его как пример.
в linuxdcpp не используются gnu autotools.
В этом случае сборка не будет заметно ускорена. (хотя остаються еще утлиты для сокращения времени компиляции - distcc и ccache)
Для проверки только что, тоже собрал этот пакет - у меня сборка заняла 5 минут 27 секунд.
Спишу на то, что у меня процессор более слабый :)
Под обновлением с нуля я имею в виду то, что прошлая сборка была завершена удалением всех объектных файлов (потому что я не хочу хранить до следующей сборки уже не "всего 328 KB", а мегабайтов 5 объектников, пусть даже в архиве).
я уже говорил, что тебе не нужно ничего хранить - emerge автоматически все почистит. Сохраняеться только исходник последней версии, что бы было к чему применять патч :)
я уже говорил, что тебе не нужно ничего хранить - emerge автоматически все почистит. Сохраняеться только исходник последней версии, что бы было к чему применять патч :)
:) Вот именно. Поэтому ускоряться нечему и в большинстве случаев пересобирать придется всё заново. Будь то linuxdcpp или OOo. И autotools тут не при чём :)
distcc, ccache и проч. - эти костыли уже не от хорошей жизни в gentoo, можно понять. :lol:
Короче, я уже было поверил в чудо, ан нет его. :(
distcc, ccache и проч. - эти костыли уже не от хорошей жизни в gentoo, можно понять. :lol:
Если ты считаешь утилиту ccache, которая сокращает время компиляции в 5-10 раз, костылями :diablo: ... то я думаю нам не стоит больше разговаривать :)
P.S. Дабы узнать больше читайте lorFAQ
Кстати, спасибо тебе ты делаешь эту тему довольно популярной :D
eleet, :lol: костыли - это образно. Все нормальные линуксоиды могут и без них обходиться в большинстве случаев. А в gentoo без них никуда. :D
lorfaq :) я вообще-то, помнится, в его составлении даже участие принимал.
Добавлено через 1 минуту
Кстати, спасибо тебе ты делаешь эту тему довольно популярной :D
ага, бесплатный циркпиар устраиваю. :D
rmn, я соглашусь с тобой, пойму наконец, что Дженту плохая система... Тогда когда мне напрямую тыкнут пальцем в те "костыли" без которых любой нормальный линуксоид может обходиться, а я использую по причине необходимости.
За lorfaq спасибо, а чем ты им там помог, если не секрет?
rmn, я соглашусь с тобой, пойму наконец, что Дженту плохая система... Тогда когда мне напрямую тыкнут пальцем в те "костыли" без которых любой нормальный линуксоид может обходиться, а я использую по причине необходимости.
:lol: сплошной флуд пошёл, завтра всё поудаляю.
Так я не понял, всё, что я писал выше - это не аргументы "против"? :D
То, что везде опция, тут - необходимость: длительные установки/сборки по ночам, спец. средства для "лишь бы быстрее собралось". :)
За lorfaq спасибо, а чем ты им там помог, если не секрет?
Хоть убей, не помню. :D Но точно пару-тройку вопросов/ответов дополнял/исправлял, когда его только-только начинали на LOR раскручивать.
В этом случае сборка не будет заметно ускорена. (хотя остаються еще утлиты для сокращения времени компиляции - distcc и ccache)
Без всяких утилит типа distcc и ccache, сборка в любом случае не будет ускоренна после очистки объектных файлов, хоть там make, хоть scons, хоть еще что-то.
я уже говорил, что тебе не нужно ничего хранить - emerge автоматически все почистит. Сохраняеться только исходник последней версии, что бы было к чему применять патч
distcc и ccache тоже ведь не из воздуха берет скомпиленные куски, поэтому хранить все-таки есть что.;)
По мне так эти утилиты тоже бубен, но если кто-то пользуется и кому-то это надо, то значит и не бубен вовсе.:D Хотя я думаю ccache - это больше для разработчиков чем для конечных пользователей. Но это всё моё скромное мнение, Вам решать что использовать.
Мне так совсем не лень все компилить, что-то большое обновляется редко, а всякую мелочь обновлять не долго. Правда, OpenOffice я так и не рискую компилить, ставлю с package. А вот эти гентушные патчи могли бы стать полезной штукой, если бы у меня были проблеммы с получением исходников. Вообще конечно система portage в Gentoo более развитая нежели ports во FreeBSD, но это и не удивительно: взять идею и реализовать хуже чем есть - это постараться надо.
eleet, а как там дела с параллельной компиляцией?
P.S.
rmn, я соглашусь с тобой, пойму наконец, что Дженту плохая система... Тогда когда мне напрямую тыкнут пальцем в те "костыли" без которых любой нормальный линуксоид может обходиться, а я использую по причине необходимости.
А мне бы кто-нибудь объяснил бы чем отличаются Linux-дистрибутивы. Ядро одно, программы тоже. А так как получаем одно и тоже, остается только выбирать из того какая система настройки (где что валяется, и чем все это правится) и система установки/обновления приложений/ядра/системы. Поэтому выбирать нужно то, что кажется более удобным.
То, что везде опция, тут - необходимость: длительные установки/сборки по ночам, спец. средства для "лишь бы быстрее собралось".
rmn, зато человек привел реальный довод в пользу Gentoo, насчет экономии трафика, хотя это и не существенно для Москвы, Питера и западных стран, но для отдаленных от центра регионов России весьма существенный факт, в том числе и для Петрозаводска - инет-то у многих не халявный.
eleet, вот почитал я темку эту и короче говоря ничего вы так и не поняли, что вам тут пытались рассказать=)
eleet, вот почитал я темку эту и короче говоря ничего вы так и не поняли, что вам тут пытались рассказать=)
Можно поподробнее?
Мне показалось, что здесь мне пытаються доказать, что бинарные дистрибутивы лучше тех, которые используют систему портов... Или я не прав?
Добавлено через 38 минут
Так я не понял, всё, что я писал выше - это не аргументы "против"? :D
То, что везде опция, тут - необходимость: длительные установки/сборки по ночам, спец. средства для "лишь бы быстрее собралось". :)
Наверное, для меня эти аргументы - крайне не убедительны :D. ИМХО, длительные компиляции компенсируются оптимизацией под архитектуру и дешевизной обновления.
Кстати совсем не обязательно все это компилировать... если так не любишь ждать, то можешь выкачивать уже готовые бинарные пакеты...
Но я не вижу в этом смысла - если уж используешь source-based дистрибутив, то потратить время на сборку для тебя не должно быть проблемой.
distcc и ccache тоже ведь не из воздуха берет скомпиленные куски, поэтому хранить все-таки есть что.;)
В общем вы правы... ccahche - это, так сказать, кэш компилятора. И он действительно что-то хранит, но ведь размер кэша легко регулируется пользователем. Да и чиститься очень просто - одной командой.
А вот distcc - это проэкт, позволяющий разделить компиляцию между несколькими компьютерами в сети. Фактически параллельная компиляция.
Больше ничего о них сказать не могу т.к. не использую
eleet, а как там дела с параллельной компиляцией?
Честно говоря, я не увлекался этим вопросом... Мне он кажеться не актуальным для машин с одним процессором.
Наверное, для меня эти аргументы - крайне не убедительны :D. ИМХО, длительные компиляции компенсируются оптимизацией под архитектуру и дешевизной обновления.
Ну, об оптимизации под архитектуру наговорено ужо много - это больше миф, чем действительность, которую можно пощупать. :)
А обновления - это уж как посмотреть. Если изначально есть в наличии исходники Debian, то обновления (безопасности, багфиксы) будут весить по несколько килобайт. Но обычно никто не заморачивается и просто делает apt-get update; apt-get upgrade :)
Мне показалось, что здесь мне пытаються доказать, что бинарные дистрибутивы лучше тех, которые используют систему портов... Или я не прав?
Ну если вы посмотрите на аватору greiv, то мне кажется он вас не стал бы склонять к бинарным дистрибутивам.
Я так же не пытаюсь доказать, что бинарные дистрибутивы лучше, т.к. сам пользуюсь source-based системой. Я константировал факт, что без "бубна" компиляция в разы не ускоряется, т.к. что-то хранить от предыдущих сборок не очень хороший вариант.
В общем вы правы... ccahche - это, так сказать, кэш компилятора. И он действительно что-то хранит, но ведь размер кэша легко регулируется пользователем. Да и чиститься очень просто - одной командой.
А вот distcc - это проэкт, позволяющий разделить компиляцию между несколькими компьютерами в сети. Фактически параллельная компиляция.
Больше ничего о них сказать не могу т.к. не использую
Чистится, не чистится - дело не в этом, а в том что исходники таких приложений как OpenOffice, KDE сами по себе в распакованном виде занимают много места + объектные файлы. У меня например несколько гигабайт исходников, если ко всем к ним буду хранить объектные файлы, то они неприемлемо много места займут.
Честно говоря, я не увлекался этим вопросом... Мне он кажеться не актуальным для машин с одним процессором.
А на процессорах с несколькими ядрами? Пока неактуален, но через пару лет все процессоры будут с несколькими ядрами, поэтому вещь заманчивая. Да и на однопроцессорной машине с одним ядром, например, параллельный make дает ощутимое ускорение.
Ну, об оптимизации под архитектуру наговорено ужо много - это больше миф, чем действительность, которую можно пощупать. :)
Да, ты прав - оптимизация совсем не заметна... Но ведь она есть! И это не может не радовать :D
К тому же, нельзя забывать про USE-флаги... Ведь сборка пакета без ненужных зависимостей, сильно ускоряет скорость его запуска и немного скорость его работы...
А обновления - это уж как посмотреть. Если изначально есть в наличии исходники Debian, то обновления (безопасности, багфиксы) будут весить по несколько килобайт. Но обычно никто не заморачивается и просто делает apt-get update; apt-get upgrade :)
В Дженту тоже, никто не заморчивается... просто делают emerge --sync; emerge --update :)
Ну если вы посмотрите на аватору greiv, то мне кажется он вас не стал бы склонять к бинарным дистрибутивам.
Я так же не пытаюсь доказать, что бинарные дистрибутивы лучше, т.к. сам пользуюсь source-based системой.
Я читал ваш длинный пост в теме "Какой Linux, Unix вы используете?" и писал не о вас. И все же не понимаю, что имел ввиду greiv.
А на процессорах с несколькими ядрами? Пока неактуален, но через пару лет все процессоры будут с несколькими ядрами, поэтому вещь заманчивая. Да и на однопроцессорной машине с одним ядром, например, параллельный make дает ощутимое ускорение.
Да действительно - вещь заманчивая. Возможно в скором времени, компиляция какого-нибудь kde будет занимать каких-то 5 минут :D.
Да действительно - вещь заманчивая. Возможно в скором времени, компиляция какого-нибудь kde будет занимать каких-то 5 минут.
Я думаю с выходом KDE4 компиляция будет занимать 5 дней.
Хотелось бы чтоб я ошибался...
Итак, как я и обещал: 3 DVD мартовского среза Gentoo от XOR.
а) доступа к фтп баттловому у меня пока нет. Подождем?
б) когда получится залить, нельзя ли будет с ним поступить так, как с дебианом? Т.е. сымитировать сетевую установку?
Alinaki, /upload открыт на запись всей Карелии :)
Логин/пароль ftp:ftp
Насчет репозитория для сет. установки - думаю, можно организовать. Только если есть какие-то подводные камни, то мне нужна инструкция.
Ок :-) завтра залью. Щас устал и спать.
А вот с инструкциями.... я сам мало что знаю как. Но постараюсь узнать.
когда получится залить, нельзя ли будет с ним поступить так, как с дебианом? Т.е. сымитировать сетевую установку?
Насчет репозитория для сет. установки - думаю, можно организовать. Только если есть какие-то подводные камни, то мне нужна инструкция.
Я думаю нужно просто смонтировать эти диски на сервере :). Вот и весь рипозиторий... Как для дебиана :)...
А чтобы им пользоваться надо будет обновить дерево портежей и добаить в make.conf строчку :
GENTOO_MIRRORS="htpp://battlefox.ru/gentoo/dvd1/ htpp://battlefox.ru/gentoo/dvd2/ htpp://battlefox.ru/gentoo/dvd3/"
(ссылки писал по аналогии с местным репозиторием дебиана)
Вот и все в принципе...
Все три двд в аплоаде. Третий двд в целом не нужен, там квака 4-я и несколько свободных прог для винды - реверанс убунте :-)
готово :)
http://battlefox.ru/gentoo/ (только для Карелии)
сами iso доступны по ftp. Просьба по возможности их не тягать и использовать сетевую установку. :)
Эх... Все равно как-то софта маловато... Хотя я все равно очень доволен :sun:
Все равно как-то софта маловато...
хы. мне на сборку того что есть жизни не хватит =) хотя... =)
sirAndrew
29.05.2007, 12:43
помогите с установкой дженту!
проблемы
1) при использовании portageм http://disk.karelia.ru/?f=eleet автоматически скачанные файлы обзываются примерно как "index.html%f=eleet%distfiles%...tar.bz2". при этом portage отказывается сам себя понимать... как избежать присвоения кривых имен при скачивании пакетов?
2) при использовании portageм ftp://battlefox.ru/battle/soft/Linux/iso/gentoo-***/dvd#
требуется логин и пароль (как известно). пытался разрулить при помощи .wgetrc - не вышло, пытался при помощи /etc/make.conf: FETCHCOMMAND="wget ... --ftpuser=#### --ftp-password=*******" - говорит логин неправильный, хотя он правильный, короче я совсем запутался!
помогите с установкой дженту!
проблемы
1) при использовании portageм http://disk.karelia.ru/?f=eleet автоматически скачанные файлы обзываются примерно как "index.html%f=eleet%distfiles%...tar.bz2". при этом portage отказывается сам себя понимать... как избежать присвоения кривых имен при скачивании пакетов?
Вообще проблематично. Нужно
1) обучить качалку понимать http-заголовок Content-Disposition. "Нестабильный" wget это умеет.
2) Качалка должна ходить на disk с измененными User-Agent
2) при использовании portageм ftp://battlefox.ru/battle/soft/Linux/iso/gentoo-***/dvd#
требуется логин и пароль (как известно). пытался разрулить при помощи .wgetrc - не вышло, пытался при помощи /etc/make.conf: FETCHCOMMAND="wget ... --ftpuser=#### --ftp-password=*******" - говорит логин неправильный, хотя он правильный, короче я совсем запутался!
вообще-то в этой теме уже писалось, что за gentoo на battle нужно по http ходить.
Насчет ключей ftp-user и ftp-password - попробуй логин и пароль заключить в одинарные кавычки, т.е.
wget URL --ftp-user='u1234' --ftp-password='passwd'
Можно в ~/.netrc прописать логин и пароль, чтоб его не светить и каждый раз в wget не вводить
machine battlefox.ru login u1234 password passwd
ну и chmod 600 ~/.netrc сделать. Хотя в данном случае, наверно, .netrc бесполезен ;)
sirAndrew
31.05.2007, 00:39
спасибо, как раз догадался что нужно использовать http://battlefox.ru/gentoo
кстати, а в городской сети есть централизованное зеркало gentoo?
может стоит организовать?
sirAndrew, зеркал нет. Если только кто-то сам не захочет его организовать :)
Более того - с батла, скорее всего, gentoo тоже будет скоро удален из-за постоянной нехватки места.
Более того - с батла, скорее всего, gentoo тоже будет скоро удален из-за постоянной нехватки места.
Можно перед удалением открыть iso-образы?
Inxo, образы были всегда открыты по ftp.
Есть небольшой вопрос...Народ, у кого нибудь есть полное собрание пакетов и софта для Gentoo(насколько я помню это около 11 DVD)....Я бы не прочь бы взять=)..
vBulletin® v3.8.4, Copyright ©2000-2024, Jelsoft Enterprises Ltd. Перевод: zCarot