Проблемы с пакетами под Linux
я обновлял openssh и openssl - ничего такого не было
сдаётся мне, ты опять что-то перепутал
там другое:
openssh-clients-3.7p1 requires openssh-3.7p1 и т.д., но не в обратную сторону, что логично
обновлять надо эти пакеты одной транзакцией, что тоже логично
сдаётся мне, ты опять что-то перепутал
там другое:
openssh-clients-3.7p1 requires openssh-3.7p1 и т.д., но не в обратную сторону, что логично
обновлять надо эти пакеты одной транзакцией, что тоже логично
>Пример нужен? Да взять хотя бы тот же glibc, ещё несколько сам видел, но уже не помню. Кроме того в инете народ часто >ругается про это в случае c openssh или openssl - сейчас тоже уже не помню как там всё это разбито на пакеты...
хорошие, блин, примеры ничего не скажешь. чего-то там видел и не помнишь чего и сообщения каких-то ломаков в инете
хорошие, блин, примеры ничего не скажешь. чего-то там видел и не помнишь чего и сообщения каких-то ломаков в инете
Ну ладно - забейте на openssh. Я его сам не обновлял, поэтому спорить не буду, но факт остаётся фактом.
> факт остаётся фактом
смешно
доказательств не будет, как я понял
смешно
доказательств не будет, как я понял
смешноglibc как пример этого я уже привёл. Других доказательств не помню - долго я с ними не мучался, забил на это и решил просто обновить нафиг всю систему вместо этих шаманств. Если бы я такой фигнёй каждый день страдал, то наверное что-то запомнил бы, а так это было достаточно давно, чтобы всяческие названия вылетели у меня из головы.
доказательств не будет, как я понял
> glibc как пример этого я уже привёл
а что с glibc?
я обновлял 2.0->2.1->2.2 и никаких лишних зависимостей не наблюдал
а что с glibc?
я обновлял 2.0->2.1->2.2 и никаких лишних зависимостей не наблюдал
возможно, никто не отрицает, если у тебя софт, утилиты скомпилины статически или если ты не затираешь сарый glibc...
череповато лишними мегабайтами на винте
череповато лишними мегабайтами на винте
а объясни в чём смысл обновления glibc'а например на шапке 6.2 с версии 2.1 до версии 2.2 ?
> а что с glibc?
А у меня оно говорило, что хочет вместе
glibc, glibc-common, glibc-devel
Хотя это может из-за того, что я слишком новую версию glibc пытался ей поставить...
А у меня оно говорило, что хочет вместе
glibc, glibc-common, glibc-devel
Хотя это может из-за того, что я слишком новую версию glibc пытался ей поставить...
Ну например когда у тебя есть работающий сервак и ты хочешь обновить у него некоторое ПО, чтобы было меньше дыр и пр., а оно говорит, что на такое старьё ставиться не будет, т.к. его скомпиляли под новое.
> А у меня оно говорило, что хочет вместе
> glibc, glibc-common, glibc-devel
ну это не совсем так
ты можешь снести glibc-devel и обновить только glibc-common и glibc
и выбрать glibc для различных подархитектур (i386, i686, athlon etc.)
> glibc, glibc-common, glibc-devel
ну это не совсем так
ты можешь снести glibc-devel и обновить только glibc-common и glibc
и выбрать glibc для различных подархитектур (i386, i686, athlon etc.)
glibc я в Слаке давно обновлял... возможно версии отличались незначительно или я что-то неправильно сделал раз у меня всё заработало. 
Надо будет постараться найти свободное время и поэксперементировать.
Надо будет постараться найти свободное время и поэксперементировать.
> чтобы было меньше дыр и пр.
есть такая вещь как security fixes от производителя дистрибутива
>его скомпиляли под новое.
в этом случае берётся правится .spec (для RH образных) или debian/rules (для Debian) и собирается пакет под конкретный дистр
есть такая вещь как security fixes от производителя дистрибутива
>его скомпиляли под новое.
в этом случае берётся правится .spec (для RH образных) или debian/rules (для Debian) и собирается пакет под конкретный дистр
Ах вот для чего они подобные геморры придумывают?
Я вообще не пытаюсь утверждать, что RedHat - уродливая система (хотя... что там всё неправильно и она не имеет право на существование. Там-то не совсем лохи работают и кое-какие здравые мысли среди этого всего можно уловить, но меня данный подход не впечатляет.
Да, те проблемы, что я описал, в общем-то просто требуют своих методов решения. Кому-то это может нравится, но не мне. Вот.
Я вообще не пытаюсь утверждать, что RedHat - уродливая система (хотя...
что там всё неправильно и она не имеет право на существование. Там-то не совсем лохи работают и кое-какие здравые мысли среди этого всего можно уловить, но меня данный подход не впечатляет.Да, те проблемы, что я описал, в общем-то просто требуют своих методов решения. Кому-то это может нравится, но не мне. Вот.
> чтобы было меньше дыр и пр.Ну дело не в наличии этих fix-ов, а в этом:
есть такая вещь как security fixes от производителя дистрибутива
>его скомпиляли под новое.Ну вот - получаем сборку из исходников!
в этом случае берётся правится .spec (для RH образных) или debian/rules (для Debian) и собирается пакет под конкретный дистр
> Ну дело не в наличии этих fix-ов,
дело и в этом тоже - при наличии фиксов для твоей версии дистрибутива ничего компилировать не надо, всё тривиально просто
> Ну вот - получаем сборку из исходников!
сборка, но упорядоченная, не приводящая к запомоиванию системы
в спеке собраны опции компиляции (не нужно вспоминать, что ты говорил ./configure прошлый раз, 3 года назад)
при апгрейде пакета все файлы корректно заменятся (если автор в новой версии изменил раскладку файлов по директориям, то все ненужные файлы удаляться)
полученный пакет может быть перенесён на другую машину (с достаточно похожей конфигурацией, а если она недостаточно похожа - то неудовлетворённые зависимости на это укажут)
дело и в этом тоже - при наличии фиксов для твоей версии дистрибутива ничего компилировать не надо, всё тривиально просто
> Ну вот - получаем сборку из исходников!
сборка, но упорядоченная, не приводящая к запомоиванию системы
в спеке собраны опции компиляции (не нужно вспоминать, что ты говорил ./configure прошлый раз, 3 года назад)
при апгрейде пакета все файлы корректно заменятся (если автор в новой версии изменил раскладку файлов по директориям, то все ненужные файлы удаляться)
полученный пакет может быть перенесён на другую машину (с достаточно похожей конфигурацией, а если она недостаточно похожа - то неудовлетворённые зависимости на это укажут)
А записывать, кстати, уже не судьба?
cat ~/.bash_history
Опять же, в той гнутой помойке, не станет более страшно,
даже если ты ещё туда что-то накатаешь.
У меня последнее время, глядя на исходники glibc, складывается ощущение, что _ЭТО_ уже ничего не спасёт.
---
...Я работаю антинаучным аферистом...
cat ~/.bash_history
Опять же, в той гнутой помойке, не станет более страшно,
даже если ты ещё туда что-то накатаешь.
У меня последнее время, глядя на исходники glibc, складывается ощущение, что _ЭТО_ уже ничего не спасёт.
---
...Я работаю антинаучным аферистом...
> А записывать, кстати, уже не судьба?
> cat ~/.bash_history
А что у тебя говорит cat ~/.bash_history | wc ?
> cat ~/.bash_history
А что у тебя говорит cat ~/.bash_history | wc ?
В данный момент, у меня он говорит:
W:\> cat ~/.bash_history | wc
Bad command or file name.
Bad command or file name.
W:\> _
У меня зоопарк из ОС, под которыми я работаю.
Особенно прикольно голосовать, не знаешь, куда и ткнуть.
---
...Я работаю...
W:\> cat ~/.bash_history | wc
Bad command or file name.
Bad command or file name.
W:\> _
У меня зоопарк из ОС, под которыми я работаю.
Особенно прикольно голосовать, не знаешь, куда и ткнуть.
---
...Я работаю...
> Опять же, в той гнутой помойке, не станет более страшно,
> даже если ты ещё туда что-то накатаешь.
Ты сравнивал? Я сравнивал.
Пакет, собранный из дистрибутивного .src.rpm с наложенными патчами и поправленным спеком, оказывается проще в сопровождении, чем поставленная через make install софтина
> А записывать, кстати, уже не судьба?
Вот люди и изобрели способ записи этого и ещё много чего.
Скажи, ты поддерживал хотя бы 5 машин на протяжении хотя бы пары лет?
> даже если ты ещё туда что-то накатаешь.
Ты сравнивал? Я сравнивал.
Пакет, собранный из дистрибутивного .src.rpm с наложенными патчами и поправленным спеком, оказывается проще в сопровождении, чем поставленная через make install софтина
> А записывать, кстати, уже не судьба?
Вот люди и изобрели способ записи этого и ещё много чего.
Скажи, ты поддерживал хотя бы 5 машин на протяжении хотя бы пары лет?
У меня зоопарк из ОС недавно вырос ещё на одну животину.
Я в рабочем для себя состоянии поддерживаю не менее трёх машин.
"net use", однако, и т.п.
---
...Я работаю...
Я в рабочем для себя состоянии поддерживаю не менее трёх машин.
"net use", однако, и т.п.
---
...Я работаю...
так вот, управление пакетами нужно людям, которые играют в другие игры
когда нужно, чтобы работало не для себя, а для других
начиная примерно с пяти машин собирать одно и то же для каждой становится реально неинтересно
начиная примерно с пары лет собирать одно и то же после обнаружения каждой дыры как-то надоедает
когда нужно, чтобы работало не для себя, а для других
начиная примерно с пяти машин собирать одно и то же для каждой становится реально неинтересно
начиная примерно с пары лет собирать одно и то же после обнаружения каждой дыры как-то надоедает
Так никто и не спорит. Но для "прорюхать" это (возможно) не будет лишним.
Я понимаю, зачем нужно управление пакетами.
Если надо собирать одно и то же, то можно написать скрипт,
который будет этим заниматься.
Останавливаться он, кстати, будет только в исключительных случаях.
Даже из исходных текстов можно собирать таким образом, кстати.
Решение всегда есть.
---
...Я работаю антинаучным аферистом...
Если надо собирать одно и то же, то можно написать скрипт,
который будет этим заниматься.
Останавливаться он, кстати, будет только в исключительных случаях.
Даже из исходных текстов можно собирать таким образом, кстати.
Решение всегда есть.
---
...Я работаю антинаучным аферистом...
трудно сказать
если с нуля взяться за LFS, то сначала долго не будет получаться ничего, и не будет удовлетворения от обучения
соответственно процесс может прерваться за отсутствием стимула до получения какой-то пользы
всё-таки помощь гуру не будет лишней, а в этом случае вариантов в выборе дистрибутива никаких нет
если с нуля взяться за LFS, то сначала долго не будет получаться ничего, и не будет удовлетворения от обучения
соответственно процесс может прерваться за отсутствием стимула до получения какой-то пользы
всё-таки помощь гуру не будет лишней, а в этом случае вариантов в выборе дистрибутива никаких нет
> Решение всегда есть.
Именно так. Другие люди это уже решили, изобретать квадратное колесо нет необходимости.
Именно так. Другие люди это уже решили, изобретать квадратное колесо нет необходимости.
Скажем так, я считаю, что сразу LFS --- вредно.
Человек не сможет осознать, почему каталоги именно так сделаны,
зачем это надо и т.п.
Но ставить виндоподобный дистрибутив, если человек разобраться хочет, тоже не стоит.
Красношапочная rc.d меня, например, раздражает.
Фиг разгребёшь.
---
...Я работаю антинаучным аферистом...
Человек не сможет осознать, почему каталоги именно так сделаны,
зачем это надо и т.п.
Но ставить виндоподобный дистрибутив, если человек разобраться хочет, тоже не стоит.
Красношапочная rc.d меня, например, раздражает.
Фиг разгребёшь.
---
...Я работаю антинаучным аферистом...
>трудно сказать
>если с нуля взяться за LFS, то сначала долго не будет получаться ничего, и не будет удовлетворения от обучения
Ну это смотря с какого нуля
>соответственно процесс может прерваться за отсутствием стимула до получения какой-то пользы
Стимул - прорюхать. Чем сложнее задача (и, возможно, способ решения?) тем больше удовольствия от процесса
>всё-таки помощь гуру не будет лишней, а в этом случае вариантов в выборе дистрибутива никаких нет
Думаю, для настоящего гуру особых проблем разница между дистрибутивами не создаст. Главное - суметь этого гуру заинтересовать
ЗЫ Вообще, спор беспредметный. Ежу понятно, что в промышленных масштабах самопал неприменим. А вот в своём огороде "интереса для" можно разок и посношаца.
>если с нуля взяться за LFS, то сначала долго не будет получаться ничего, и не будет удовлетворения от обучения
Ну это смотря с какого нуля
>соответственно процесс может прерваться за отсутствием стимула до получения какой-то пользы
Стимул - прорюхать. Чем сложнее задача (и, возможно, способ решения?) тем больше удовольствия от процесса
>всё-таки помощь гуру не будет лишней, а в этом случае вариантов в выборе дистрибутива никаких нет
Думаю, для настоящего гуру особых проблем разница между дистрибутивами не создаст. Главное - суметь этого гуру заинтересовать
ЗЫ Вообще, спор беспредметный. Ежу понятно, что в промышленных масштабах самопал неприменим. А вот в своём огороде "интереса для" можно разок и посношаца.
> Ну это смотря с какого нуля
посмотри на историю постов автора треда
> Чем сложнее задача (и, возможно, способ решения?) тем больше удовольствия от процесса
Одной сложности мало. Нужно, чтобы задача была разделена на обозримые этапы, и достижение каждого из них приносило удовлетворение.
> Думаю, для настоящего гуру особых проблем разница между дистрибутивами не создаст. Главное - суметь этого гуру заинтересовать.
Ага. Вот приходит такой к гуру и говорит: "у меня в шлаквари русских букв не видно", а тот: "а нефиг было всякое говно ставить, у меня вот всё видно". Всё, занятие окончено
> Ежу понятно, что в промышленных масштабах самопал неприменим.
Применим, если он лучше, чем то, что дядя сделал, и настолько, чтобы окупить затраты на поддержку.
> А вот в своём огороде "интереса для" можно разок и посношаца.
Нужно! И не один раз (одним и не обойтись ггг)!
Только поможет это лишь при определённых условиях, см.выше.
посмотри на историю постов автора треда
> Чем сложнее задача (и, возможно, способ решения?) тем больше удовольствия от процесса
Одной сложности мало. Нужно, чтобы задача была разделена на обозримые этапы, и достижение каждого из них приносило удовлетворение.
> Думаю, для настоящего гуру особых проблем разница между дистрибутивами не создаст. Главное - суметь этого гуру заинтересовать.
Ага. Вот приходит такой к гуру и говорит: "у меня в шлаквари русских букв не видно", а тот: "а нефиг было всякое говно ставить, у меня вот всё видно". Всё, занятие окончено
> Ежу понятно, что в промышленных масштабах самопал неприменим.
Применим, если он лучше, чем то, что дядя сделал, и настолько, чтобы окупить затраты на поддержку.
> А вот в своём огороде "интереса для" можно разок и посношаца.
Нужно! И не один раз (одним и не обойтись ггг)!
Только поможет это лишь при определённых условиях, см.выше.
>Ага. Вот приходит такой к гуру и говорит: "у меня в шлаквари русских букв не видно"
Под словом "заинтересовать" я понимал нечто более прозаическое
Под словом "заинтересовать" я понимал нечто более прозаическое
Для этого учебные центры должны быть и всё такое.
Или в подмастерья идти (то есть работать под руководством гуру, чтобы постепенно достигнуть его уровня).
И во всех случаях выбор будет не за учеником.
Или в подмастерья идти (то есть работать под руководством гуру, чтобы постепенно достигнуть его уровня).
И во всех случаях выбор будет не за учеником.
> Одной сложности мало.
> Нужно, чтобы задача была разделена на обозримые этапы,
> и достижение каждого из них приносило удовлетворение.
Напоминает правило Рескина.
>> Думаю, для настоящего гуру особых проблем разница между
>> дистрибутивами не создаст.
>> Главное - суметь этого гуру заинтересовать.
> Ага. Вот приходит такой к гуру и говорит:
> "у меня в шлаквари русских букв не видно",
> а тот: "а нефиг было всякое говно ставить, у меня вот всё видно".
> Всё, занятие окончено
Ну, положим, настроить терминал на этом уровне совсем простая задача.
Кроме того, описана в FAQ.
>> Ежу понятно, что в промышленных масштабах самопал неприменим.
> Применим, если он лучше, чем то, что дядя сделал,
> и настолько, чтобы окупить затраты на поддержку.
Вы чего?
Вы хоть раз видели готовые решения для промышленных масштабов?
Или вы только о частях?
Так, там и смысл-то в том, чтобы эти части увязать.
Или под словом "самопал" понимается что-то другое?
---
...Я работаю антинаучным аферистом...
> Нужно, чтобы задача была разделена на обозримые этапы,
> и достижение каждого из них приносило удовлетворение.
Напоминает правило Рескина.
>> Думаю, для настоящего гуру особых проблем разница между
>> дистрибутивами не создаст.
>> Главное - суметь этого гуру заинтересовать.
> Ага. Вот приходит такой к гуру и говорит:
> "у меня в шлаквари русских букв не видно",
> а тот: "а нефиг было всякое говно ставить, у меня вот всё видно".
> Всё, занятие окончено
Ну, положим, настроить терминал на этом уровне совсем простая задача.
Кроме того, описана в FAQ.
>> Ежу понятно, что в промышленных масштабах самопал неприменим.
> Применим, если он лучше, чем то, что дядя сделал,
> и настолько, чтобы окупить затраты на поддержку.
Вы чего?
Вы хоть раз видели готовые решения для промышленных масштабов?
Или вы только о частях?
Так, там и смысл-то в том, чтобы эти части увязать.
Или под словом "самопал" понимается что-то другое?
---
...Я работаю антинаучным аферистом...
<offtopic>
Предлагаю ввести правило - тем, кто отвечает на посты тов. КОНТРА, ставить (+)
</offtopic>
Предлагаю ввести правило - тем, кто отвечает на посты тов. КОНТРА, ставить (+)
</offtopic>
Я тоже сейчас примерно об этом подумал 
А обоснование?
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
Испугался? Шутка, ггг
Просто, непонятно.
Например, непонятно, что подразумевается под "промышленными масштабами".
---
...Я работаю антинаучным аферистом...
Например, непонятно, что подразумевается под "промышленными масштабами".
---
...Я работаю антинаучным аферистом...
сборка, но упорядоченная, не приводящая к запомоиванию системыВ Слаке достаточно средств, чтобы достаточно просто решать эти проблемы.
в спеке собраны опции компиляции (не нужно вспоминать, что ты говорил ./configure прошлый раз, 3 года назад)
при апгрейде пакета все файлы корректно заменятся (если автор в новой версии изменил раскладку файлов по директориям, то все ненужные файлы удаляться)
полученный пакет может быть перенесён на другую машину (с достаточно похожей конфигурацией, а если она недостаточно похожа - то неудовлетворённые зависимости на это укажут)
Какие там средства, чтобы управлять установкой софта, взятого не из дистрибутива (а в дистрибутиве, как было замечено, много чего нет)?
Собирать правильный пакет с нуля? Это намного сложнее, чем чуть-чуть подправить готовый, который работает почти как надо.
Собирать правильный пакет с нуля? Это намного сложнее, чем чуть-чуть подправить готовый, который работает почти как надо.
Какие там средства, чтобы управлять установкой софта, взятого не из дистрибутиваНу ты наверное знаешь, что там есть свои пакеты. Они достаточно простые и в этом их прелесть. Они легко делаются вручную.
(а в дистрибутиве, как было замечено, много чего нет)?В дистрибутиве там есть почти всё необходимое. А то что там нету 10 различных cron, inetd, sendmail - это даже скорее плюс, т.к. процесс выбора пакета при установке занимает гораздо меньше времени. И кроме того там не так много "левых" пакетов, которые в других дистрибутивах тоже приходится отсеивать.
Собирать правильный пакет с нуля? Это намного сложнее, чем чуть-чуть подправить готовый, который работает почти как надо.Процесс сборки большинства пакетов там тоже можно подправить для более новых версий и прочего.
А если такого не оказалось - то создать по образу и подобию тоже не очень сложно будет.
>Ну дело не в наличии этих fix-ов, а в этом:
мне наверно никогда не понять зачем ставить новую версию софтины, когда задача стоит только закрыть дыру
>Ну вот - получаем сборку из исходников!
согласись, что эта сборка отличается от
./configure
make
make install
и после неё получается пакет, который находится под контролем менеджера пакетов вследствии чего
эту программу будет легко снести, а также можно будет поставить пакеты зависящие от него
мне наверно никогда не понять зачем ставить новую версию софтины, когда задача стоит только закрыть дыру
>Ну вот - получаем сборку из исходников!
согласись, что эта сборка отличается от
./configure
make
make install
и после неё получается пакет, который находится под контролем менеджера пакетов вследствии чего
эту программу будет легко снести, а также можно будет поставить пакеты зависящие от него
> А записывать, кстати, уже не судьба?
>cat ~/.bash_history
нашёл куда записывать опции ./configure
>cat ~/.bash_history
нашёл куда записывать опции ./configure
Я знаю, что там есть пакеты (говорят, недавно даже зависимости им приделали, или я перепутал с чем-то?)
Однако, все, пропагандирующие слаку, пропагандируют также установку через make install, не исключая и тебя.
Наверное, эти пакеты не дают больших преимуществ
Мне кажется, различие больше психологическое. Если система, созданная разработчиками дистрибутива, хорошая, то её не хочется ломать.
> В дистрибутиве там есть почти всё необходимое. А то что там нету 10 различных cron, inetd, sendmail - это даже скорее плюс, т.к. процесс выбора пакета при установке занимает гораздо > меньше времени.
Лично я не фанат установки малознакомой системы "на скорость". С этим к KOHТPA А если система знакомая, то выбрать просто.
А собирать postfix сразу после установки меня бы заломало, т.к. никакого удовольствия я от этого процесса не испытываю. Так что довольно важно, что идёт в дистрибутиве.
Например, в Debian есть всё, поэтому я до сих пор не умею толком собирать пакеты - нет необходимости. Однако если она возникнет - проблем не будет, весь процесс очень хорошо документирован, в силу особенностей устройства Debian-сообщества.
Однако, все, пропагандирующие слаку, пропагандируют также установку через make install, не исключая и тебя.
Наверное, эти пакеты не дают больших преимуществ
Мне кажется, различие больше психологическое. Если система, созданная разработчиками дистрибутива, хорошая, то её не хочется ломать.
> В дистрибутиве там есть почти всё необходимое. А то что там нету 10 различных cron, inetd, sendmail - это даже скорее плюс, т.к. процесс выбора пакета при установке занимает гораздо > меньше времени.
Лично я не фанат установки малознакомой системы "на скорость". С этим к KOHТPA
А если система знакомая, то выбрать просто.А собирать postfix сразу после установки меня бы заломало, т.к. никакого удовольствия я от этого процесса не испытываю. Так что довольно важно, что идёт в дистрибутиве.
Например, в Debian есть всё, поэтому я до сих пор не умею толком собирать пакеты - нет необходимости. Однако если она возникнет - проблем не будет, весь процесс очень хорошо документирован, в силу особенностей устройства Debian-сообщества.
>Если надо собирать одно и то же, то можно написать скрипт,
этот скрипт уже есть и называется он rpm в RH'образных системах и
dpkg-buildpackage в Debian
зачем очередной раз изобретать велосипед?
этот скрипт уже есть и называется он rpm в RH'образных системах и
dpkg-buildpackage в Debian
зачем очередной раз изобретать велосипед?
мне наверно никогда не понять зачем ставить новую версию софтины, когда задача стоит только закрыть дыруА как это делается по-другому?
Эти фиксы обновляют только изменившиеся файлы из дистрибутива? Даже если так, то всё равно мы получим новую версию софта, как бы мы его не обновляли. согласись, что эта сборка отличается отПро наличие пакетов, например, в Слаквари я уже писал.
./configure
make
make install
и после неё получается пакет, который находится под контролем менеджера пакетов вследствии чего
эту программу будет легко снести, а также можно будет поставить пакеты зависящие от него
Однако, все, пропагандирующие слаку, пропагандируют также установку через make install, не исключая и тебя.Значит ты меня неправильно понял - установку, через make install я не пропагандирую!
Наверное, эти пакеты не дают больших преимуществ
Лично я не фанат установки малознакомой системы "на скорость". С этим к KOHТPA А если система знакомая, то выбрать просто.Да дело не в том знакомая система или нет. Просто набор пакетов Шапки и тем более Дебиана при установке больше набора пакетов при установке в Слаке. А пакеты всё-равно выбирать приходится или хотя бы посмотреть на них.
> Значит ты меня неправильно понял - установку, через make install я не пропагандирую!
Ты реально собираешь пакеты? Good
А как насчёт:
- создания своего репозитория пакетов, модифицированных либо собранных с нуля (последнее нужно очень редко, только для очень нового софта либо тобой написанного
чтобы быстро перенести из на все машины (apt-get upgdate && apt-get upgrade или поставить базовый комплект на новую (apt-get install task- )
- безболезненного обновления старых инсталляций, с сохранением пересобранного тобой софта
- продуманных и документированных правил сборки пакетов, которые гарантируют мирное сосуществование твоих пакетов с дистрибутивными, и с неофициальными, если их авторы тоже следуют правилам (это Debian policy)
> А пакеты всё-равно выбирать приходится или хотя бы посмотреть на них.
А зачем мне на них смотреть, когда я знаю, что требуется от инсталляции и какой софт для этого нужен?
Ты реально собираешь пакеты? Good
А как насчёт:
- создания своего репозитория пакетов, модифицированных либо собранных с нуля (последнее нужно очень редко, только для очень нового софта либо тобой написанного
чтобы быстро перенести из на все машины (apt-get upgdate && apt-get upgrade или поставить базовый комплект на новую (apt-get install task-
)- безболезненного обновления старых инсталляций, с сохранением пересобранного тобой софта
- продуманных и документированных правил сборки пакетов, которые гарантируют мирное сосуществование твоих пакетов с дистрибутивными, и с неофициальными, если их авторы тоже следуют правилам (это Debian policy)
> А пакеты всё-равно выбирать приходится или хотя бы посмотреть на них.
А зачем мне на них смотреть, когда я знаю, что требуется от инсталляции и какой софт для этого нужен?
>А как это делается по-другому? Эти фиксы обновляют только изменившиеся файлы из дистрибутива? Даже если так, то всё >равно мы получим новую версию софта, как бы мы его не обновляли.
ну например в Debian 3.0r0 samba версии 2.2.3a-6 (2.2.3a версия самбы, -6 версия пакета)
в самбе нашли дыру с получением прав рута удалённо, ты что сразу побежишь выкачивать
и компилять версию 2.2.8a (или в какой там это дыру исправили) ? Я сделаю просто -
скачаю обновление с security.debian.org - samba-2.2.3a-12.3 , заметь версия самбы при этом не изменилась,
а дыра закрыта
ну например в Debian 3.0r0 samba версии 2.2.3a-6 (2.2.3a версия самбы, -6 версия пакета)
в самбе нашли дыру с получением прав рута удалённо, ты что сразу побежишь выкачивать
и компилять версию 2.2.8a (или в какой там это дыру исправили) ? Я сделаю просто -
скачаю обновление с security.debian.org - samba-2.2.3a-12.3 , заметь версия самбы при этом не изменилась,
а дыра закрыта
> Ты реально собираешь пакеты? Good
Ну да... с некоторого времени начал обновлять у себя ПО через пакеты.
> А как насчёт:
Да я вот когда-то предлагал:
Только я пакеты себе под Слаку делаю.
Ну да... с некоторого времени начал обновлять у себя ПО через пакеты.
> А как насчёт:
Да я вот когда-то предлагал:
Только я пакеты себе под Слаку делаю.
А зачем мне на них смотреть, когда я знаю, что требуется от инсталляции и какой софт для этого нужен?Что-то я не понял... ты при установки что-ли full ему говоришь?
ну например в Debian 3.0r0 samba версии 2.2.3a-6 (2.2.3a версия самбы, -6 версия пакета)А думаешь откуда это берётся? Они же не лезут в бинарник, чтобы поменять там пару asm-инструкций
в самбе нашли дыру с получением прав рута удалённо, ты что сразу побежишь выкачивать
и компилять версию 2.2.8a (или в какой там это дыру исправили) ? Я сделаю просто -
скачаю обновление с security.debian.org - samba-2.2.3a-12.3 , заметь версия самбы при этом не изменилась,
а дыра закрыта
. В большинстве случаев появляется патч для сырца и из него получаем залатанную прогу. Патчи для сырца появляются точно не позднее, чем обновления на security.debian.org> > А как насчёт:
> Да я вот когда-то предлагал:
мимо тазика
то есть совсем
> Что-то я не понял... ты при установки что-ли full ему говоришь?
После установки base system просто ставится весь необходимый софт, поимённо, с помощью apt-get install
Можно и дальше автоматизировать (до одной команды на каждую типичную задачу но пока у меня нет списка типичных задач - слишком мало машин
> Да я вот когда-то предлагал:
мимо тазика
то есть совсем
> Что-то я не понял... ты при установки что-ли full ему говоришь?
После установки base system просто ставится весь необходимый софт, поимённо, с помощью apt-get install
Можно и дальше автоматизировать (до одной команды на каждую типичную задачу но пока у меня нет списка типичных задач - слишком мало машин
После установки base system просто ставится весь необходимый софт, поимённо, с помощью apt-get installКто-то говорил, что его заломает после каждой установки postfix ставить.
Можно и дальше автоматизировать (до одной команды на каждую типичную задачу но пока у меня нет списка типичных задач - слишком мало маши
> Кто-то говорил, что его заломает после каждой установки postfix ставить.
И кто же это был?
И кто же это был?
Последнее время версии идут так: <major> . <minor> . <patch>
Поэтому закрытие дыры связано с изменением версии.
---
...Я работаю антинаучным аферистом...
Поэтому закрытие дыры связано с изменением версии.
---
...Я работаю антинаучным аферистом...
Я их туда не записываю!
Они туда сами попадают!
А серьёзно,
cat <<EOF >> ~/configs/Makefile
<package>:
cd ~/src/<package>
./configure <options>
make
EOF
---
...Я работаю антинаучным аферистом...
Они туда сами попадают!
А серьёзно,
cat <<EOF >> ~/configs/Makefile
<package>:
cd ~/src/<package>
./configure <options>
make
EOF
---
...Я работаю антинаучным аферистом...
Кстати, в сети видел "правильный" способ установки системы на новую машину. ; )
Что-то в роде
find / -ev -print | cpio -p /mnt/туда-то
---
...Я работаю антинаучным аферистом...
Что-то в роде
find / -ev -print | cpio -p /mnt/туда-то
---
...Я работаю антинаучным аферистом...
Но ведь собрать postfix можно один раз и ставить его потом сколько угодно раз
потом "вычищать" эту систему замучаешься, я так один раз Debian 3.0 ставил на систему со специфическим SCSI контроллером поддержка которого только в 2.4.22 появилась (установочные дискеты на 2.4.18 а разбираться с тем как делаются установочные дискеты заломало
вообщем никому не советую такой метод установки, лучше уж пару часов потратить и понять как на дискеты с инсталлером новое ядро запихивается
вообщем никому не советую такой метод установки, лучше уж пару часов потратить и понять как на дискеты с инсталлером новое ядро запихивается
> потом "вычищать" эту систему замучаешься
он будет не мучиться, а наслаждаться
он будет не мучиться, а наслаждаться
> Но ведь собрать postfix можно один раз и ставить его потом сколько угодно раз
Можно и так.
А можно применить дальнейшие оптимизации:
1) не собирать ни одного раза, а брать готовый
2) воспользоваться готовым инструментом, который одной командой скачает пакет из архива, и установит, и со всеми необходимыми библиотеками то же самое проделает
Можно и так.
А можно применить дальнейшие оптимизации:
1) не собирать ни одного раза, а брать готовый
2) воспользоваться готовым инструментом, который одной командой скачает пакет из архива, и установит, и со всеми необходимыми библиотеками то же самое проделает
А это скорее дело вкуса, а не оптимальности.
Почему же, второй пункт - дело скорости
Ну скорость естественно разная, но разница несущественная по-моему.
Там на то "; )" стоит. : )
Лично я так тоже не советую.
А вот установку лучше всего делать всё-таки способом
mkdir application-major.minor
cd application-major.minor
tar zxf /path/to/application.tgz
И наделать ссылки.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Karel Capek
Лично я так тоже не советую.
А вот установку лучше всего делать всё-таки способом
mkdir application-major.minor
cd application-major.minor
tar zxf /path/to/application.tgz
И наделать ссылки.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Karel Capek
>И наделать ссылки.
сслыки в /usr/bin ?
а как их потом вычищать?
сслыки в /usr/bin ?
а как их потом вычищать?
Как и всякие висячие.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Karel Capek
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Karel Capek
остануться другие проблемы:
- создание ссылок на бинарники в /usr/bin
- создание ссылок на либы в /usr/lib
- а если прога тянет за собой инклудники, то что делать?
- какая-нибудь прога для сборки хочет наличие сотни прог которых ты установил таким образом, то
что ей в ./configure будешь указывать сотню опций?
- как помнить что у тебя стоит а что не стоит?
- ........
вообщем как не крути менеджеры пакетов рулят
PS кстати не ты в своё время на ЛОР высказал идею с такой установкой прог ?
тогда того чела опустили по полной программе :-) кажется в треде про "русских физиков" оно было
- создание ссылок на бинарники в /usr/bin
- создание ссылок на либы в /usr/lib
- а если прога тянет за собой инклудники, то что делать?
- какая-нибудь прога для сборки хочет наличие сотни прог которых ты установил таким образом, то
что ей в ./configure будешь указывать сотню опций?
- как помнить что у тебя стоит а что не стоит?
- ........
вообщем как не крути менеджеры пакетов рулят
PS кстати не ты в своё время на ЛОР высказал идею с такой установкой прог ?
тогда того чела опустили по полной программе :-) кажется в треде про "русских физиков" оно было
А кого не ЛОР не опускают гыгы?
На самом деле, это таки можно довести до ума, и таки получится новый формат пакетов новый менеджер пакетов, который таки будет управлять этими символическими ссылками.
Вопрос лишь в том, будет ли результат стоить потраченного труда?
На самом деле, это таки можно довести до ума, и таки получится новый формат пакетов новый менеджер пакетов, который таки будет управлять этими символическими ссылками.
Вопрос лишь в том, будет ли результат стоить потраченного труда?
"ЛОР" это что?
Видимо, меня там никогда не было и не бывает.
> остануться другие проблемы:
> - создание ссылок на бинарники в /usr/bin
1. Там не должно лежать ничего.
2. Его вообще не должно быть.
> - создание ссылок на либы в /usr/lib
"/lib", ты хотел сказать?
> - а если прога тянет за собой инклудники, то что делать?
Это зачем?
И что мешает?
> - какая-нибудь прога для сборки хочет наличие сотни прог которых ты
> установил таким образом, то
> что ей в ./configure будешь указывать сотню опций?
Она их вызывать будет?
Все ссылки лежат в "/bin"
> - как помнить что у тебя стоит а что не стоит?
ls /installed
> - ........
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Karel Capek
Видимо, меня там никогда не было и не бывает.
> остануться другие проблемы:
> - создание ссылок на бинарники в /usr/bin
1. Там не должно лежать ничего.
2. Его вообще не должно быть.
> - создание ссылок на либы в /usr/lib
"/lib", ты хотел сказать?
> - а если прога тянет за собой инклудники, то что делать?
Это зачем?
И что мешает?
> - какая-нибудь прога для сборки хочет наличие сотни прог которых ты
> установил таким образом, то
> что ей в ./configure будешь указывать сотню опций?
Она их вызывать будет?
Все ссылки лежат в "/bin"
> - как помнить что у тебя стоит а что не стоит?
ls /installed
> - ........
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Karel Capek
Оставить комментарий
tokuchu
> примеры именно такого случая можно?> я давно не встречал такого
> в такой ситуации надо ставить оба пакета одной командой
Как это ставить я знаю, но само наличие подобных вещей не делает жизнь прекраснее. Пример нужен? Да взять хотя бы тот же glibc, ещё несколько сам видел, но уже не помню. Кроме того в инете народ часто ругается про это в случае c openssh или openssl - сейчас тоже уже не помню как там всё это разбито на пакеты...