ru.unix.bsd

 
 - RU.UNIX.BSD ------------------------------------------------------------------
 From : Valentin Nechayev                    2:5020/400     19 Nov 2004  13:29:39
 To : eugen@grosbein.pp.ru
 Subject : Re: переход с 4.10 на 5.3
 -------------------------------------------------------------------------------- 
 

 >>> Eugene Grosbein wrote: 
 
  EG>>> Вылечил через /usr/compat и LD_PRELOAD.
  VN>> Вот именно что начинается использование таких костылей. Причём ты
  VN>> ограничился
  VN>> случаем одного бинарника и одной библиотеки. Как только начнётся
  VN>> необходимость
  VN>> делать то же самое для массы приложений, бэкапить комплекты библиотек,
  VN>> причём
  VN>> в процессе перехода получится, что они будут разные для разных приложений
  VN>> -
  VN>> у тебя начнётся такой бардак, что снести всё это нахер и собрать заново
  VN>> будет сокращением головной боли в десять раз.
 EG> Hе вижу проблемы. Библиотеки все гуртом идут в /usr/compat один раз,
 
 Да не поможет это!
 У тебя будет одинаковое название с одинаковым номером у двух библиотек,
 одна в основном каталоге, другая в compat. ld.so с таким не разберётся,
 у него нет критериев, чтобы разобраться.
 И тут ты начнёшь строить костыли в виде libmap.conf, LD_PRELOAD и так далее,
 рассказывая для каждого конкретного бинарника, где именно ему надо брать
 те или иные библиотеки?
 Уж лучше статикой собирать - надёжнее будет. Кстати, это и хорошая рекомендация
 для всего что ограничивается списком библиотек при старте.
 
 EG> на всякий случай. Если такой случай случается, то болезная старая софтинка
 EG> насильно линкуется со старой библиотекой и живет дальше до апгрейда
 EG> по потребности. Вообще такие конфликты - когда номер версии либы
 EG> не меняется - случаются редко на сервере, с десктопом конечно все хуже.
 
 И какой смысл вообще держать в таком случае на сервере старые пакеты,
 жизнь которых поддерживается через одно общеизвестное место, если там
 схема зависимостей значительно проще?
 -netch-
 --- ifmail v.2.15dev5.3
  * Origin: Dark side of coredump (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор