Bug 6851

А в чем собственно проблема с libgecko? На чем именно конфликт?

Ну собственно уже не в чём, после того как идея libgecko не нашла поддержки. 
Я успешно эксплуатировал вариант, когда общие для проектов mozilla, firefox, 
sunbird, nvu, thunderbird библиотеки входили в libgecko, и не таскали каждый 
свою. 
Никому не надо - ладно, я мегабайты не экономлю. 

Я готов поучаствовать в эконмике...
Экономика должна быть экономна...:)

Я пытался - сделал libgecko, куда вошли все эти библиотеки. Чтобы это жило в 
системе, mozilla не должна класть ссылки в /usr/lib. Чтобы была экономия, из 
каталогов всей указанной семейки нужно удалить файлы, которые уже есть в 
libgecko. 
Но есть и аргументы против: 
"Этому пакету пока не место в Сизифе - он сыр по идейным параметрам :) 
libgecko и прочие libxx из seamonkey будут собраны и востребованы лишь только 
когда этого захотят сами разработчики seamonkey. В ближайшем будущем этого не 
предвидится. Поэтому я и прошу убрать этот пакет - пусть он лежит где-нибудь в 
сторонке (например в Дедале). 
--  
WBR, Konstantin Lepikhov 

Для меня этот пакет (libgecko) не имеет смысла - т.к. сейчас в Сизифе уже есть
xulrunner, который и так провайдит все эти библиотеки вместо libgecko (и это
более правильно логически) + я готовлю rpm с nss/libnspr, которая будет
провайдить все остальные ssl/pki библиотеки. Для старой mozilla-suite надо
действительно профиксить rpath (если его уже не пофиксили), чтобы она лазила за
своими либами в /usr/lib/mozilla, т.к. они уже скоро будут несовместимы ни с
tb/fx, ни с seamonkey. Т.е. правильная связка такова:
xulrunner - gecko runtime + xul runtime
nss - ssl/crypto/pki
nspr - libnspr
и текущему мантейнеру suite надо уже смотреть на seamonkey и притирать его к
"правильной связке".

Во :) 
Повторил просьбу в incoming@ удалить libgecko 

Сейчас firefox, thunderbird & co переходят на единую платформу - xulrunner.
Соответственно через некоторое время он переедит в /usr/lib . Как я понимаю,
seamonkey - это единственное gecko-based приложение, не идущее по этому пути.
Поэтому очень не хочется, чтобы в будуйщем возникли конфликты между mozilla и
xulrunner. 

Я присоединяюсь к просьбе Константина и тоже прошу убрать библиотеки из /usr/lib.

(In reply to comment #7) 
> Я присоединяюсь к просьбе Константина и тоже прошу убрать библиотеки 
из /usr/lib. 
Вообще-то багу вешал я и речь шла о библиотеках из mozilla, кладомых 
в /usr/lib :) 
И вообще, так как последнее время mozilla пакетит Константин, то я вообще не 
понимаю, может ли он просить сам себя :) 
 
 

Я стал следующим бойцом с этим творением:) Так что просят меня... :)

Едет 1.7.12 - там убрано /usr/lib/*.so.
В предверии появления SeaMonkey меня интересует судьбы
/usr/include/{nspr,nss}, где обещанные пакеты, дабы убрать конфликт между двумя
версиями мозилы...

17.10.05 идет nspr собираемый из cvs (в нем сейчас 4.7.0).
На счет nss сейчас думаю.

Хм... Пока что продукты mozilla используют 4.5.1, и еще две недели назад я
подготовил 4.6(актуальную на тот момент), но из-за давки с OOo 2.0 заливать не
стал... Ну так кто возьмет на себя libnspr, я или вы?

(In reply to comment #12)
> Хм... Пока что продукты mozilla используют 4.5.1, и еще две недели назад я
> подготовил 4.6(актуальную на тот момент), но из-за давки с OOo 2.0 заливать не
> стал... Ну так кто возьмет на себя libnspr, я или вы?

У меня уже все готово. 
Я хочу на nspr завязать еще и xulrunner ... a ему нужен самый свежий. Если вы не
против, то я его возьму. 

Я не против. Самое главное чтобы mozilla-suite & seamonkey сработались с новой
версией, а то at@ со своим поиском дублирующихся символов заспамит... :)

(In reply to comment #14)
> Я не против. Самое главное чтобы mozilla-suite & seamonkey сработались с новой
> версией, а то at@ со своим поиском дублирующихся символов заспамит... :)

Не вижу причин чтобы mozilla c ним не собралась. Только вам придется приложить
один патч для этого :)
В firefox я наткнулся на то, что она не может собраться с внешним nspr . Для
сборки с ней нужен патч. Причем падает она в nss. Как только я оторву nspr
положу патч.
Если вам это удастся раньше буду рад воспользоваться вашими трудами.

Для этих писем есть мощный инструмент - /dev/null. Оттуда еще никто не созвращался.

С mozilla-suite патчей нужно намного больше... Я как раз занимаюсь убеждением
сборочной среды в необходимости таки собраться с внешним libnspr... А затем и
libnss :)